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Abstract  At  present,  designers  of  real-time  systems  face  a  dilemma  between  expressive¬ 
ness  and  automatic  verification:  if  they  can  specify  some  aspects  of  their  system  in  some 
automaton-based  formalism,  then  automatic  verification  is  possible;  but  more  complex  sys¬ 
tem  components  may  be  hard  or  impossible  to  express  in  such  decidable  formalisms.  These 
more  complex  components  may  still  be  simulated;  but  there  is  then  little  support  for  their 
formal  analysis.  The  main  goal  of  Real-Time  Maude  is  to  provide  a  way  out  of  this  dilemma, 
while  complementing  both  decision  procedures  and  simulation  tools.  Real-Time  Maude  em¬ 
phasizes  ease  and  generality  of  specification,  including  support  for  distributed  real-time 
object-based  systems.  Because  of  its  generality,  falling  outside  of  decidable  system  classes, 
the  formal  analyses  supported — including  symbolic  simulation,  breadth-first  search  for  fail¬ 
ures  of  safety  properties,  and  model  checking  of  time-bounded  temporal  logic  properties — 
are  in  general  incomplete  (although  they  are  complete  for  discrete  time).  These  analysis 
techniques  have  been  shown  useful  in  finding  subtle  bugs  of  complex  systems,  clearly  out¬ 
side  the  scope  of  current  decision  procedures.  This  paper  describes  both  the  semantics  of 
Real-Time  Maude  specifications,  and  of  the  formal  analyses  supported  by  the  tool.  It  also 
explains  the  tool’s  pragmatics,  both  in  the  use  of  its  features,  and  in  its  application  to  con¬ 
crete  examples. 
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1  Introduction 

At  present,  designers  of  real-time  systems  face  a  dilemma  between  expressiveness  and  au¬ 
tomatic  verification.  If  they  can  specify  some  aspects  of  their  system  in  a  more  restricted 
automaton-based  formalism,  then  automatic  verification  of  system  properties  may  be  ob¬ 
tained  by  specialized  model  checking  decision  procedures.  But  this  may  be  difficult  or  im¬ 
possible  for  more  complex  system  components  which  may  be  hard  or  impossible  to  express 
in  such  decidable  formalisms.  In  that  case,  simulation  offers  greater  modeling  flexibility,  but 
is  typically  quite  weak  in  the  kinds  of  formal  analyses  that  can  be  performed.  The  main  goal 
of  Real-Time  Maude  is  to  provide  a  way  out  of  this  dilemma,  while  complementing  both 
decision  procedures  and  simulation  tools. 

On  the  one  hand,  Real-Time  Maude  can  be  seen  as  complementing  tools  based  on  timed 
and  linear  hybrid  automata,  such  as  UPPAAL  [19,5],  HyTech  [15],  and  Kronos  [32].  While 
the  restrictive  specification  formalism  of  these  tools  ensures  that  interesting  properties  are 
decidable,  such  finite-control  automata  do  not  support  well  the  specification  of  larger  sys¬ 
tems  with  different  communication  models  and  advanced  object-oriented  features.  By  con¬ 
trast,  Real-Time  Maude  emphasizes  ease  and  generality  of  specification,  including  support 
for  distributed  real-time  object-based  systems.  The  price  to  pay  for  increased  expressive¬ 
ness  is  that  many  system  properties  may  no  longer  be  decidable.  However,  this  does  not 
diminish  either  the  need  for  analyzing  such  systems,  or  the  possibility  of  using  decision 
procedures  when  applicable.  On  the  other  hand,  Real-Time  Maude  can  also  be  seen  as  com¬ 
plementing  traditional  testbeds  and  simulation  tools  by  providing  a  wide  range  of  formal 
analysis  techniques  and  a  more  abstract  specification  formalism  in  which  different  forms  of 
communication  can  be  easily  modeled  and  can  be  both  simulated  and  formally  analyzed. 
Finally,  some  tools  geared  toward  modeling  and  analyzing  larger  real-time  systems,  such  as, 
e.g.,  IF  [6],  extend  timed  automaton  techniques  with  explicit  UML-inspired  constructions 
for  modeling  objects,  communication,  and  some  notion  of  data  types.  Real-Time  Maude 
complements  such  tools  not  only  by  the  full  generality  of  the  specification  language  and  the 
range  of  analysis  techniques,  but,  most  importantly,  by  its  simplicity  and  clarity:  A  simple 
and  intuitive  formalism  is  used  to  specify  both  the  data  types  (by  equations )  and  dynamic 
and  real-time  behavior  of  the  system  (by  rewrite  rules).  Furthermore,  the  operational  seman¬ 
tics  of  a  Real-Time  Maude  specification  is  clear  and  easy  to  understand. 

A  key  goal  of  this  work  is  to  document  the  tool’s  theoretical  foundations,  based  on  a 
simplified  semantics  of  real-time  rewrite  theories  [23,28]  made  possible  by  some  recent  de¬ 
velopments  in  the  foundations  of  rewriting  logic  [7];  these  simplified  theoretical  foundations 
are  explained  in  Section  3.  We  also  give  a  precise  description  of  the  semantics  of  Real-Time 
Maude  specifications  and  of  its  symbolic  execution  and  formal  analysis  commands.  Such 
semantics  is  given  by  means  of  a  family  of  theory  transformations,  that  associate  to  a  real¬ 
time  rewrite  theory  and  a  command  a  corresponding  ordinary  rewrite  theory  (a  Maude  [9, 
10]  system  module)  and  a  Maude  command  with  the  intended  semantics  (Section  5).  Be¬ 
sides  thus  giving  a  precise  account  of  the  tool’s  semantics,  we  also  explain  and  illustrate  its 
pragmatics  in  several  ways: 


1.  We  discuss  different  time  domains  (both  discrete  and  continuous)  provided  by  the  sys¬ 
tem,  which  also  allows  the  user  to  define  new  such  time  domains  in  Maude  modules. 

2.  We  then  explain  the  general  methods  by  which  tick  rules  for  advancing  time  in  the 
system  can  be  defined. 
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3.  We  also  explain  some  general  techniques  to  specify  object-oriented  real-time  systems 
in  Real-Time  Maude;  such  techniques  have  been  developed  through  a  good  number  of 
substantial  case  studies  and  have  proved  very  useful  in  practice. 

4.  We  give  an  overview  of  the  tool’s  language  features,  commands,  and  analysis  capabili¬ 
ties  (Section  4). 

5.  We  illustrate  the  tool’s  use  in  practice  by  means  of  two  examples  (Section  6). 

Real-Time  Maude  specifications  are  executable  formal  specifications.  Our  tool  offers 
various  simulation,  search,  and  model  checking  techniques  which  can  uncover  subtle  mis¬ 
takes  in  a  specification.  Timed  rewriting  can  simulate  one  of  the  many  possible  concurrent 
behaviors  of  the  system.  Timed  search  and  time-bounded  linear  temporal  logic  model  check¬ 
ing  can  analyze  all  behaviors — relative  to  a  given  time  sampling  strategy  for  dense  time  as 
explained  in  Section  4.2.1 — from  a  given  initial  state  up  to  a  certain  time  bound.  By  restrict¬ 
ing  search  and  model  checking  to  behaviors  up  to  a  certain  time  bound  and  with  a  given 
time  sampling  strategy,  the  set  of  reachable  states  is  typically  restricted  to  a  finite  set,  which 
can  be  subjected  to  model  checking.  Search  and  model  checking  are  “incomplete”  for  dense 
time,  since  there  is  no  guarantee  that  the  chosen  time  sampling  strategy  covers  all  interest¬ 
ing  behaviors.  However,  all  the  large  systems  we  have  modeled  in  Real-Time  Maude  so  far 
have  had  a  discrete  time  domain,  and  in  this  case  search  and  model  checking  can  completely 
cover  all  behaviors  from  the  initial  state.  For  further  analysis,  the  user  can  write  his/her  own 
specific  analysis  and  verification  strategies  using  Real-Time  Maude’s  reflective  capabilities. 

The  Real-Time  Maude  tool  described  in  this  paper  is  a  mature  and  quite  efficient  tool 
available  free  of  charge  (with  sources,  a  tool  manual,  examples,  case  studies,  and  papers) 
from  http://www.ifi.uio.no/RealTimeMaude.  The  tool  has  been  used  in  a  number  of 
substantial  applications,  a  subset  of  which  is  listed  in  Section  6.4.  Real-Time  Maude  is 
based  on  earlier  theoretical  work  on  the  rewriting  logic  specification  of  real-time  and  hy¬ 
brid  systems  [23,28],  and  has  benefited  from  the  extensive  experience  gained  with  an  earlier 
tool  prototype  [27,23],  which  was  applied  to  specify  and  analyze  a  sophisticated  multicast 
protocol  suite  [23,26].  As  mentioned  above,  the  current  tool  has  simpler  foundations  based 
on  more  recent  theoretical  advances.  Furthermore,  thanks  to  the  efficient  support  of  breadth- 
first  search  and  of  on-the-fly  LTL  model  checking  in  the  underlying  Maude  2  system  [10],  on 
top  of  which  it  is  implemented,  the  current  tool  supports  symbolic  simulation,  search  for  vi¬ 
olations  of  safety  properties,  and  model  checking  of  time-bounded  temporal  logic  properties 
with  good  efficiency. 


2  Equational  Logic,  Rewriting  Logic,  and  Maude 

Since  Real-Time  Maude  extends  Maude  and  its  underlying  rewriting  logic  formalism,  we 
first  present  some  background  on  equational  logic,  rewriting  logic,  and  Maude. 


2.1  Equational  and  Rewriting  Logic 

Membership  equational  logic  (MEL)  [22]  is  a  typed  equational  logic  in  which  data  are 
first  classified  by  kinds  and  then  further  classified  by  sorts,  with  each  kind  k  having  an 
associated  set  S &  of  sorts,  so  that  a  datum  having  a  kind  but  not  a  sort  is  understood  as 
an  error  or  undefined  element.  Given  a  MEL  signature  E,  we  write  Tz,k  and  Xz:(A)fc 
to  denote,  respectively,  the  set  of  ground  E -terms  of  kind  k,  and  of  E -terms  of  kind  k  over 
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variables  in  X,  where  X  =  {®i  :  k\ , . . . ,  xn  :  kn}  is  a  set  of  kinded  variables.  Atomic  formulas 
have  either  the  form  t  =  t!  (Z-equation)  or  t  :  s  (Z-membership)  with  t,  t'  G  Tr  (A'A  and 
s  G  S)~;  and  E-sentences  are  universally  quantified  Horn  clauses  on  such  atomic  formulas. 
A  MEL  theory  is  then  a  pair  ( E,E )  with  E  a  set  of  Z-sentences.  Each  such  theory  has 
an  initial  algebra  T^/E  whose  elements  are  equivalence  classes  of  ground  terms  modulo 
provable  equality. 

In  the  general  version  of  rewrite  theories  over  MEL  theories  defined  in  [7],  a  rewrite 
theory  is  a  tuple  =  ( E,E,(p,R )  consisting  of:  (i)  a  MEL  theory  (Z,E);  (ii)  a  func¬ 
tion  (p\E  — >  ^f(N)  assigning  to  each  function  symbol  f:  k\  ■  ■  ■  kn  — >  k  in  E  a  set  <p(/)  C 
{ 1 , . . . ,  n}  of  frozen  argument  positions',  (iii)  a  set  R  of  (universally  quantified)  labeled  con¬ 
ditional  rewrite  rules  r  having  the  general  form 

(VA)  r  .  t  >  t  if  Ate/  Pi  =  Qi  A  A jeJ  wj  •  si  A  A zeL  ^  ^ i 

where,  for  appropriate  kinds  k  and  ki,  t ,  t!  G  Tx(A)fc  and  ti,  t[  G  Tz (A) j.,  for  l  G  L. 

The  function  <p  specifies  which  arguments  of  a  function  symbol  f  cannot  be  rewritten, 
which  are  called  frozen  positions.  Given  a  rewrite  theory  &  =  ( E,E,(p,R ),  a  sequent  of 
Sf  is  a  pair  of  (universally  quantified)  terms  of  the  same  kind  t,  t' ,  denoted  (VA)  (  — >  t' 
with  A  =  {xi  :  k\, . . .  ,xn  :  kn}  a  set  of  kinded  variables  and  t ,  t'  G  Tv(A)fc  for  some  k.  We 
say  that  M  entails  the  sequent  (VA)  t  — » t! ,  and  write  £%  h  (VA)  t  — >  t' ,  if  the  sequent 
(VA )  (  — >  t'  can  be  obtained  by  means  of  the  inference  rules  of  reflexivity,  transitivity, 
congruence,  and  nested  replacement  given  in  [7]. 

To  any  rewrite  theory  =  (E,  E,  (p,  R)  we  can  associate  a  Kripke  structure  AT lf%,  k)Ln 
in  a  natural  way  provided  we:  (i)  specify  a  kind  k  in  E  so  that  the  set  of  states  is  defined  as 
T x/E,k’  and  define  a  set  17  of  (possibly  parametric)  atomic  propositions  on  those  states; 
such  propositions  can  be  defined  equationally  in  a  protecting  extension  (E  U  17,17  U  D)  D 
(E,E),  and  give  rise  to  a  labeling  function  Ln  on  the  set  of  states  Tz/E,k  in  the  obvious 
way.  The  transition  relation  of  JtT h)Ln  is  the  one-step  rewriting  relation  of  M,  to  which 
a  self-loop  is  added  for  each  deadlocked  state.  The  semantics  of  linear-time  temporal  logic 
(LTL)  formulas  is  defined  for  Kripke  structures  in  the  well-known  way  (e.g.,  [8, 10]).  In 
particular,  for  any  LTL  formula  t ft  on  the  atomic  propositions  17  and  an  initial  state  [t],  we 
have  a  satisfaction  relation  k)En,  [(]  |=  t ft  which  can  be  model  checked,  provided 

the  number  of  states  reachable  from  [f]  is  finite.  Maude  [10]  provides  an  explicit-state  LTL 
model  checker  precisely  for  this  purpose. 


2.2  Maude  and  its  Formal  Analysis  Features 

A  Maude  module  specifies  a  rewrite  theory  {E,EU  A,(p,R),  with  E  a  set  of  conditional 
equations  and  memberships,  and  A  a  set  of  equational  axioms  such  as  associativity,  com¬ 
mutativity,  and  identity,  so  that  equational  deduction  is  performed  modulo  the  axioms  A. 
Intuitively,  the  theory  (E,  EU  A)  specifies  the  system’s  state  space  as  an  algebraic  data  type, 
and  each  rewrite  rule  r  in  R  specifies  a  (family  of)  one-step  transition(s)  from  a  substitution 
instance  of  t  to  the  corresponding  substitution  instance  of  t' ,  provided  that  the  substitution 
satisfies  the  condition  of  the  rule.  The  rewrite  rules  are  applied  modulo  the  equations  E  U  A. 1 

1  Operationally,  a  term  is  reduced  to  its  E-normal  form  modulo  A  before  any  rewrite  rule  is  applied  in 
Maude.  Under  the  coherence  assumption  [31]  this  is  a  complete  strategy  to  achieve  the  effect  of  rewriting  in 
E  U  /1-equivalence  classes. 
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We  briefly  summarize  the  syntax  of  Maude.  Functional  modules  and  system  modules 
are,  respectively,  MEL  theories  and  rewrite  theories,  and  are  declared  with  respective  syn¬ 
tax  fmod  .  .  .  endfm  and  mod  .  .  .  endm.  Object-oriented  modules  provide  special  syntax 
to  specify  concurrent  object-oriented  systems,  but  are  entirely  reducible  to  system  modules; 
they  are  declared  with  the  syntax  (omod  .  .  .  endom) . 2  Immediately  after  the  module’s  key¬ 
word,  the  name  of  the  module  is  given.  After  this,  a  list  of  imported  submodules  can  be 
added.  One  can  also  declare  sorts 3,  subsorts,  and  operators.  Operators  are  introduced  with 
the  op  keyword.  They  can  have  user-definable  syntax,  with  underbars  marking  the  argu¬ 
ment  positions,  and  are  declared  with  the  sorts  of  their  arguments  and  the  sort  of  their  result. 
Some  operators  can  have  equational  attributes,  such  as  assoc,  comm,  and  id,  stating,  for  ex¬ 
ample,  that  the  operator  is  associative  and  commutative  and  has  a  certain  identity  element. 
Such  attributes  are  then  used  by  the  Maude  engine  to  match  terms  modulo  the  declared  ax¬ 
ioms.  The  operator  attribute  ctor  declares  that  the  operator  is  a  constructor,  as  opposed  to  a 
defined  function.  This  attribute  does  not  have  any  computational  effect  in  Real-Time  Maude. 
There  are  three  kinds  of  logical  statements:  equations,  introduced  with  the  keywords  eq  and, 
for  conditional  equations,  ceq;  memberships,  declaring  that  a  term  has  a  certain  sort  and  in¬ 
troduced  with  the  keywords  mb  and  cmb;  and  rewrite  rules,  introduced  with  the  keywords  rl 
and  crl.  The  mathematical  variables  in  such  statements  are  either  explicitly  declared  with 
the  keywords  var  and  vars,  or  can  be  introduced  on  the  fly  in  a  statement  without  being 
declared  previously,  in  which  case  they  must  have  the  form  var :  sort.  Finally,  a  comment  is 

preceded  by  “***’  or  ‘ - ’  and  lasts  until  the  end  of  the  line. 

Maude  modules  are  executable  under  reasonable  assumptions.  The  high  performance 
Maude  engine — which  can  perform  up  to  millions  of  rewrites  per  second — provides  the 
following  analysis  commands: 

-  A  rewrite  (rew)  and  a  “fair”  rewrite  (f  rew)  command,  which  execute  one  rewrite  sequence — 
out  of  possibly  many — from  a  given  initial  state. 

-  A  search  command  (search)  for  analyzing  all  possible  rewrite  sequences  from  a  given 
initial  state  to,  by  performing  a  breadth-first  search  to  check  whether  terms  matching 
certain  patterns  can  be  reached  from  to-  The  search  does  not  terminate  if  the  set  of  states 
reachable  from  to  is  infinite  and  the  desired  state(s)  are  not  reachable  from  to. 

-  A  linear  temporal  logic  model  checker  [14],  comparable  to  Spin  [17]  in  performance, 
which  checks  whether  each  rewrite  sequence  from  a  given  initial  state  to  satisfies  a 
certain  linear  temporal  logic  (LTL)  formula.  LTL  model  checking  will  normally  not 
terminate  if  the  state  space  reachable  from  to  is  infinite. 

A  propositional  LTL  formula  is  constructed  by  the  usual  LTL  operators  (see,  e.g.,  [10, 

14]  and  Section  4.2.2)  and  a  set  17  of  user-defined  (possibly  parametric)  atomic  propo¬ 
sitions.  Such  atomic  propositions  should  be  defined  as  terms  of  the  built-in  sort  Prop,  in 
a  module  that  includes  the  built-in  Maude  module  MODEL-CHECKER.  The  labeling  func¬ 
tion  Li 7  is  defined  by  equations  of  the  form  t  I  =  p  =  b  if  C,  for  a  (possibly)  paramet¬ 
ric  atomic  proposition  p  (i.e.,  for  p  a  term  of  sort  Prop),  a  term  t  of  the  built-in  kind 
[State] ,  a  term  b  of  kind  [Bool] ,  and  a  condition  C .  It  is  sufficient  to  define  when  a 
predicate  holds.  For  example,  if  p  were  the  only  proposition,  then  Ljt(M)  =  (c(p)  | 

<7  ground  substitution  A  (BU  A)  b  (V0)  u  |  =  cr(p)  =  true}  [10]. 

-  Finally,  the  user  may  define  her  own  specific  execution  strategies  using  Maude’s  reflec¬ 
tive  capabilities  [11, 12]. 

2  In  Full  Maude,  and  in  its  extension  Real-Time  Maude,  module  declarations  and  execution  commands 
must  be  enclosed  by  a  pair  of  parentheses. 

3  Kinds  are  not  declared  explicitly;  the  kind  to  which  sort  s  belongs  is  written  [s] . 
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We  refer  to  the  Maude  manual  [10]  for  a  more  thorough  description  of  Maude’s  analysis 
capabilities. 

2.2.1  Object-Oriented  Specification  in  Maude 

In  object-oriented  (Full)  Maude4  modules  one  can  declare  classes  and  subclasses.  A  class 
declaration 

class  C  I  att\  :  si ,  ...  ,  attn  :  sn  . 

declares  an  object  class  C  with  attributes  atti  to  attn  of  sorts  si  to  sn.  An  object  of  class  C 
in  a  given  state  is  represented  as  a  term 

<  O  :  C  |  att\  :  val\ , ...,  attn  :  valn  > 

of  the  built-in  sort  Object,  where  O  is  the  object’s  name  or  identifier,  and  where  val\  to 
valn  are  the  current  values  of  the  attributes  att\  to  attn  and  have  sorts  si  to  sn.  Objects  can 
interact  with  each  other  in  a  variety  of  ways,  including  the  sending  of  messages.  A  message 
is  a  term  of  the  built-in  sort  Msg,  where  the  declaration 

msg  m  :  Pi  »..  pn  ~>  Msg  . 

defines  the  name  of  the  message  (m)  and  the  sorts  of  its  parameters  (pi  ...  pn).  In  a  concur¬ 
rent  object-oriented  system,  the  state,  which  is  usually  called  a  configuration  and  is  a  term 
of  the  built-in  sort  Configuration,  has  typically  the  structure  of  a  multiset  made  up  of  ob¬ 
jects  and  messages.  Multiset  union  for  configurations  is  denoted  by  a  juxtaposition  operator 
(empty  syntax)  that  is  declared  associative  and  commutative  and  having  the  none  multiset 
as  its  identity  element,  so  that  order  and  parentheses  do  not  matter,  and  so  that  rewriting  is 
multiset  rewriting  supported  directly  in  Maude.  The  dynamic  behavior  of  concurrent  object 
systems  is  axiomatized  by  specifying  each  of  its  concurrent  transition  patterns  by  a  rewrite 
rule.  For  example,  the  configuration  on  the  left-hand  side  of  the  rule 

rl  [1]  :  m(0,w)  <  0  :  C  I  al  :  x,  a2  :  y,  a3  :  z  >  => 

<0  :  C  |  al  :  x  +  w,  a2  :  y,  a3  :  z  >  m’(y,x)  . 

contains  a  message  m,  with  parameters  0  and  w,  and  an  object  0  of  class  C.  The  message 
m(0,w)  does  not  occur  in  the  right-hand  side  of  this  rule,  and  can  be  considered  to  have 
been  removed  from  the  state  by  the  rule.  Likewise,  the  message  m’  (y  ,x)  only  occurs  in  the 
configuration  on  the  right-hand  side  of  the  rule,  and  is  thus  generated  by  the  rule.  The  above 
rule,  therefore,  defines  a  (parameterized  family  of)  transition(s)  in  which  a  message  m(0,w) 
is  read,  and  consumed,  by  an  object  0  of  class  C,  with  the  effect  of  altering  the  attribute  al 
of  the  object  and  of  sending  a  new  message  m  ’  (y ,  x) .  Attributes,  such  as  a3  in  our  example, 
whose  values  do  not  change  and  do  not  affect  the  next  state  of  other  attributes  need  not 
be  mentioned  in  a  rule.  Attributes,  like  a2,  whose  values  influence  the  next  state  of  other 
attributes  or  the  values  in  messages,  but  are  themselves  unchanged,  may  be  omitted  from 
right-hand  sides  of  rules.  Thus  the  above  rule  could  also  be  written 

rl  [1]  :  m(0,w)  <  0  :  C  I  al  :  x,  a2  :  y  >  => 

<0:C|al:x+w>  m’ (y,x)  . 

A  subclass  inherits  all  the  attributes  and  rules  of  its  superclasses5. 

4  Real-Time  Maude  is  built  on  top  of  Full  Maude  [10.  Part  II],  which  extends  Maude  with  support  for 
object-oriented  specification  and  advanced  module  operations. 

5  The  attributes  and  rules  of  a  class  cannot  be  modified  by  its  subclasses,  which  may  of  course  have 
additional  attributes  and  rules. 
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3  Real-Time  Rewrite  Theories  Revisited 

In  [28]  we  proposed  to  specify  real-time  and  hybrid  systems  in  rewriting  logic  as  real-time 
rewrite  theories,  and  defined  an  extension  of  the  basic  model  to  include  the  possibility  of 
defining  eager  and  lazy  rewrite  rules.  This  section  first  recalls  the  definition  of  real-time 
rewrite  theories,  and  then  explains  why  the  generalization  of  rewriting  logic  given  in  [7]  has 
made  the  partition  into  eager  and  lazy  rules  unnecessary. 


3.1  Real-Time  Rewrite  Theories 

A  real-time  rewrite  theory  is  a  rewrite  theory  where  some  rules,  called  tick  rules,  model  time 
elapse  in  a  system,  while  “ordinary"  rewrite  rules  model  instantaneous  change. 

Definition  1  A  real-time  rewrite  theory  is  a  tuple  (32,tj),x),  where  3$  =  ( E,E,(p,R ) 
is  a  (generalized)  rewrite  theory,  such  that 

-  0  is  an  equational  theory  morphism  0  :  TIME  — >  (E,  E)  from  the  theory  TIME  to 
the  underlying  equational  theory  of  3?,  that  is,  0  interprets  TIME  in  32;  the  theory 
TIME  [28]  defines  time  abstractly  as  an  ordered  commutative  monoid  ( Time,0,  +,  <) 
with  additional  operators  such  as  —  (where  x  —  y  denotes  x  —  y  if  y  <  x,  and  0  otherwise) 
and  <; 

-  (E,E)  contains  a  sort  System  (denoting  the  state  of  the  system),  and  a  specific  sort 
GlobalSystem  with  no  subsorts  or  supersorts  and  with  only  one  operator 

:  System^  GlobalSystem 

which  satisfies  no  non-trivial6  equations;  furthermore,  the  sort  GlobalSystem  does  not 
appear  in  the  arity  of  any  function  symbol  in  E ; 

-  T  is  an  assignment  of  a  term  T;  of  sort  0  ( Time)  to  every  rewrite  rule 

l :  It} — >{f'}  if  cond 

involving  terms  of  sort  GlobalSystem7 ;  if  T;  ^  0  (0)  we  call  the  rule  a  tick  rule  and  write 

l :  Ity^Ult1}  if  cond. 

The  term  T;  denoting  the  duration  of  the  tick  rule  may  contain  variables,  including  vari¬ 
ables  that  do  not  occur  in  t,  t! ,  and/or  cond.  For  example,  if  x \  is  a  variable  x  not  oc¬ 
curring  in  either  t  or  cond,  then  time  can  advance  nondeterministically  by  any  amount 
from  a  substitution  instance  of  It}  where  the  substitution  satisfies  cond. 

The  global  state  of  the  system  should  have  the  form  {«},  in  which  case  the  form  of  the 
tick  rules  ensures  that  time  advances  uniformly  in  all  parts  of  the  system.  The  total  time 
elapse  t(cc)  of  a  rewrite  a  :  It} — >It'}  of  sort  GlobalSystem  is  the  sum  of  the  times 
elapsed  in  each  tick  rule  application  [28].  We  write  32,§.x  b  It.}  It.1}  if  there  is  a  proof 
a  :  It}  — >  It1}  in 3$^^  with  x (a)  =  r.  Furthermore,  we  write  Time 0^, . . . ,  for  0(  Time), 
0(0),  etc. 

6  By  "trivial”  equations  we  mean  equations  of  the  form  t  =  t. 

7  All  rules  involving  terms  of  sort  GlobalSystem  are  assumed  to  have  different  labels. 
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3.2  Eager  and  Lazy  Rules  Revisited 

The  motivation  behind  having  eager  and  lazy  rewrite  rules  was  to  model  urgency  by  letting 
the  application  of  instantaneous  eager  rules  take  precedence  over  the  application  of  lazy 
tick  rules  [28].  This  feature  was  supported  in  version  1  of  Real-Time  Maude.  The  ability  to 
defin e  frozen  operators  in  rewriting  logic  [7]  means  that  it  is  no  longer  necessary  to  explicitly 
define  eager  and  lazy  rules.  Instead,  one  may  define  a  frozen  operator8 

eagerEnabled  :  s  — >  [Bool]  [frozen  (1)] 

for  each  sort  s  that  can  be  rewritten,  introduce  an  equation 

eager Enabled (t)  =  true  if  cond 

for  each  “eager”  rule  t  — >  t'  if  cond ,  and  add  an  equation 

eag  er Enabled  (f  (x\ ,xn))  =  true  if  eager  Enabled  [xi )  =  true 

for  each  operator  /  and  each  position  i  which  is  not  a  frozen  position  in  /.  A  “lazy”  tick  rule 
should  now  have  the  form 

l  :  {_ty  — l-+  it'y  if  cond  A  eager Enabled ({i})  true. 

This  technique  makes  unnecessary  any  explicit  support  for  eager  and  lazy  rules  at  the  system 
definition  level  to  model  urgency.  In  addition,  the  lazy/eager  feature  has  not  been  needed  in 
any  Real-Time  Maude  application  we  have  developed  so  far.  Real-Time  Maude  2  therefore 
does  not  provide  explicit  support  for  defining  eager  and  lazy  rules. 


4  Specification  and  Execution  in  Real-Time  Maude 

This  section  gives  an  overview  of  how  to  specify  real-time  rewrite  theories  in  Real-Time 
Maude  as  timed  modules,  and  how  to  execute  such  modules  in  the  tool.  In  particular,  Sec¬ 
tion  4.1.5  presents  some  useful  techniques  for  specifying  object-oriented  real-time  systems 
in  Real-Time  Maude.  The  manual  [24]  explains  our  tool  in  much  more  detail. 


4.1  Specification  in  Real-Time  Maude  2.1 

Real-Time  Maude  extends  Full  Maude  [10]  to  support  the  specification  of  real-time  rewrite 
theories  as  timed  modules  and  object-oriented  timed  modules.  Such  modules  are  entered  at 
the  user  level  by  enclosing  them  in  parentheses  and  including  the  module  body  between 
the  keywords  tmod  and  endtm,  and  between  tomod  and  endtom,  respectively.  To  state  non¬ 
executable  properties,  Real-Time  Maude  allows  the  user  to  specify  real-time  extensions  of 
abstract  Full  Maude  theories.  Since  Real-Time  Maude  extends  Full  Maude,  we  can  also 
define  Full  Maude  modules  in  the  tool.  All  the  usual  operations  on  modules  provided  by 
Full  Maude  are  supported  in  Real-Time  Maude. 

8  By  '  [frozen  (1)]  ’  we  mean  that  the  first  (and  in  this  case  only)  argument  of  the  corresponding  oper¬ 
ator  ( eagerEnabled )  cannot  be  rewritten  (see  Section  2.1).  That  is,  even  if  t  rewrites  to  u,  it  is  not  the  case 
that  eagerEnabled(t)  rewrites  to  eagerEnabled. ( u). 
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4.1.1  Specifying  the  Time  Domain 

The  equational  theory  morphism  0  in  a  real-time  rewrite  theory  Mq.-c  is  not  given  explicitly 
at  the  specification  level.  Instead,  by  default,  any  timed  module  automatically  imports  the 
following  functional  module  TIME9: 

fmod  TIME  is 

sorts  Time  NzTime  .  subsort  NzTime  <  Time  . 
op  zero  :  ->  Time  . 

op  _plus_  :  Time  Time  ->  Time  [assoc  comm  prec  33  gather  (E  e)]  . 
op  _monus_  :  Time  Time  ->  Time  [prec  33  gather  (E  e)]  . 
ops  _le_  _lt_  _ge_  _gt_  :  Time  Time  ->  Bool  [prec  37]  . 
eq  zero  plus  R:Time  =  RrTime  . 

eq  R:Time  le  R’ :Time  =  (RrTime  It  R’ rTime)  or  (RrTime  ==  R’ rTime)  . 

eq  RrTime  ge  R’ rTime  =  R’ rTime  le  RrTime  . 

eq  RrTime  gt  R’ rTime  =  R’ rTime  It  RrTime  . 

endfm 

The  morphism  0  implicitly  maps  Time  to  Time,  0  to  zero,  _  +  _  to  _plus_,  _  <  _  to  _le_,  etc. 
Even  though  Real-Time  Maude  assumes  a  fixed  syntax  for  time  operations,  the  tool  does  not 
build  in  a  fixed  model  of  time.  In  fact,  the  user  has  complete  freedom  to  specify  the  desired 
data  type  of  time  values — which  can  be  either  discrete  or  dense  and  need  not  be  linear — by 
specifying  the  data  elements  of  sort  Time,  and  by  giving  equations  interpreting  the  con¬ 
stant  zero  and  the  operators  _plus_,  _monus_,  and  _lt_,  so  that  the  axioms  of  the  theory 
TIME  [28]  are  satisfied.  The  predefined  Real-Time  Maude  module  NAT-TIME-DOMAIN  de¬ 
fines  the  time  domain  to  be  the  natural  numbers  as  follows: 

fmod  NAT-TIME-DOMAIN  is  including  LTIME  .  protecting  NAT  . 
subsort  Nat  <  Time  .  subsort  NzNat  <  NzTime  . 
vars  N  N'  :  Nat  . 
eq  zero  =  0  . 
eq  N  plus  N>  =  N  +  N’  . 

eq  N  monus  N’  =  if  N  >  N’  then  sd(N,  N’)  else  0  fi  . 
eq  N  It  N’  =  N  <  N’  . 
endfm 

To  have  dense  time,  the  user  can  import  the  predefined  module  POSRAT-TIME-  DOMAIN, 
which  defines  the  nonnegative  rationals  to  be  the  time  domain.  The  set  of  predefined  mod¬ 
ules  in  Real-Time  Maude  also  includes  a  module  LTIME,  which  assumes  a  linear  time  do¬ 
main  and  defines  the  operators  max  and  min  on  the  time  domain,  and  the  modules  TIME-INF, 
LTIME-INF,  NAT-TIME-DOMAIN-  WITH-INF,  and  POSRAT-TIME-DOMAIN-WITH-INF  which  ex¬ 
tend  the  respective  time  domains  with  an  “infinity”  value  INF  in  a  supersort  Timelnf  of 
Time.  Detailed  specifications  for  all  these  time  domains  can  be  found  in  [24,  Appendix  A]. 


4.1.2  Tick  Rules 

A  timed  module  automatically  imports  the  module  TIMED-PRELUDE  which  contains  the  dec¬ 
larations 

sorts  System  GlobalSystem  . 

op  {_)-  :  System  ->  GlobalSystem  [ctor]  . 

Tt  ,  . 

A  conditional  tick  rule  l :  it}  — » it  >  if  cond  is  written  with  syntax 

The  operator  attributes  prec  and  gather  deal  with  parsing;  their  meaning  is  explained  in  [10]. 
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crl  [0  :  {O  =>  it'}  in  time  T i  if  cond  . 

and  with  similar  syntax  for  unconditional  rules. 

We  do  not  require  time  to  advance  beyond  any  time  bound,  or  the  specification  to  be 
“non-Zeno.”  However,  it  seems  sensible  to  require  that  if  time  can  advance  by  r  plus  r' 
time  units  from  a  state  {f }  in  one  application  of  a  tick  rule,  then  it  should  also  be  possible  to 
advance  time  by  r  time  units  from  the  same  state  using  the  same  tick  rule.  Tick  rules  should 
(in  particular  for  dense  time)  typically  have  one  of  the  forms 


crl 

111 

ity  => 

an 

in 

time 

X 

if 

cond 

A  x 

le  u 

A 

cond' 

[nonexec]  . 

(t), 

crl 

in 

m  => 

it'} 

in 

time 

X 

if 

cond 

A  x 

It  u 

A 

cond' 

[nonexec]  . 

(t), 

crl 

in 

m  => 

it'} 

in 

time 

X 

if 

cond 

[nonexec] 

(*), 

rl 

in 

ity  => 

it'} 

in 

time 

X 

[nonexec]  . 

(§), 

where  a:  is  a  variable  of  sort  Time  (or  of  a  subsort  of  Time)  which  does  not  occur  in  {t} 
and  which  is  not  initialized  in  the  condition.  The  term  u  denotes  the  maximum  amount  by 
which  time  can  advance  in  one  tick  step.  Each  variable  in  u  should  either  occur  in  t  or 
be  instantiated  in  cond  by  matching  equations  (see  [10]).  The  (possibly  empty)  conditions 
cond  and  cond'  should  not  further  constrain  x  (except  possibly  by  adding  the  condition 
x  =/=  zero).  Tick  rules  in  which  the  duration  term  contains  a  variable  that  does  not  occur 
in  the  rule’s  lefthand  side  and  is  not  initialized  by  matching  equations  in  the  rule’s  condition 
are  called  time-nondeterministic.  All  other  tick  rules  are  called  time-deterministic  and  can 
be  used  e.g.  in  discrete  time  domains. 

Real-Time  Maude  assumes  that  tick  rule  applications  in  which  time  advances  by  zero  do 
not  change  the  state  of  the  system.  A  tick  rule  is  admissible  if  its  zero-time  applications  do 
not  change  the  state,  and  it  is  either  a  time-deterministic  tick  rule  or  a  time-nondeterministic 
tick  rule  of  any  of  the  above  forms — possibly  with  le  and  It  replaced  by  <=  and  <  (in 
which  case  le  and  <=,  and  It  and  <,  should  be  equivalent  on  the  time  domain).  The  exe¬ 
cution  of  admissible  tick  rules  is  supported  by  the  Real-Time  Maude  tool.  However,  time- 
nondeterministic  tick  rules  are  not  directly  executable  by  the  underlying  Maude  engine, 
since  many  choices  are  possible  for  instantiating  the  time  variable  x  (that  is  why  they  are 
specified  with  the  nonexec  attribute,  which  tells  Maude  that  these  rules  are  not  intended  to 
be  executed  before  they  have  been  treated  by  Real-Time  Maude).  Real-Time  Maude  exe¬ 
cutes  such  rules  using  a  time  sampling  strategy  (see  Sections  4.2.1  and  5.2)  specified  by  the 
user. 


4.1.3  Defining  Initial  States 

For  the  purpose  of  conveniently  defining  initial  states,  Real-Time  Maude  allows  the  user  to 
introduce  operators  of  sort  GlobalSystem.  Each  ground  term  of  sort  GlobalSystem  must 
reduce  to  a  term  of  the  form  it}  using  the  equations  in  the  specification.  The  constant 
initState  on  page  30  is  an  example  of  an  operator  of  sort  GlobalSystem  which  reduces  to 
a  term  of  the  desired  form. 


4.1.4  Timed  Object-Oriented  Modules 

Maude’s  object  model  can  be  extended  to  the  real-time  setting  by  just  adding  a  subsort 
declaration 


subsort  Configuration  <  System  . 
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where  Configuration  is  the  sort  whose  elements  are  multisets  of  messages  and  objects. 
Timed  object-oriented  modules  extend  both  object-oriented  and  timed  modules  to  provide 
support  for  object-oriented  real-time  systems.  In  contrast  to  untimed  object-oriented  sys¬ 
tems,  functions  such  as  8  and  rate  (described  below),  and  the  tick  rules,  will  manipu¬ 
late  the  global  configuration.  It  is  therefore  useful  to  have  a  richer  sort  structure  for  con¬ 
figurations.  Timed  object-oriented  modules  include  subsorts  for  nonempty  configurations 
(NEConf  iguration),  configurations  without  messages  (ObjectConf  iguration)  or  without 
objects  (MsgConf  iguration),  etc.  Real-Time  Maude  automatically  adds  the  subsort  decla¬ 
ration  Configuration  <  System  to  timed  object-oriented  modules.  Section  6.2  gives  an 
example  of  a  timed  object-oriented  module. 

4.1.5  Useful  Techniques  for  Object-Oriented  Specification  in  Real-Time  Maude 

In  this  section  we  present  some  techniques  for  specifying  object-oriented  systems  in  Real- 
Time  Maude  that  have  proved  useful  in  all  our  larger  case  studies.  These  specification  tech¬ 
niques  provide  a  more  elegant  and  natural  way  of  specifying  object-oriented  systems  than 
those  given  in  [28],  This  improvement  is  due  to  the  possibility  of  having  frozen  operators  in 
version  2  of  Maude  (and  in  Real-Time  Maude). 

In  larger  object-oriented  systems  it  is  usually  the  case  that  an  unbounded  number  of 
objects  could  be  affected  by  the  elapse  of  time  and/or  could  affect  the  maximum  time  elapse 
in  a  tick  step.  For  such  systems,  we  have  found  it  useful  to  have  functions 

op  8  :  Configuration  Time  ->  Configuration  [frozen  (1)]  . 
and 

op  rate  :  Configuration  ->  Timelnf  [frozen  (1)]  . 

to  define,  respectively,  the  effect  of  passage  of  time  on  a  configuration,  and  the  maximum 
time  elapse  possible  from  a  configuration,  and  to  let  these  functions  distribute  over  the  ele¬ 
ments  in  a  configuration  according  to  the  following  equations: 

vars  NeC  NeC’  :  NEConf iguration  .  var  R  :  Time  . 

eq  8 (none,  R)  =  none  . 

eq  5 (NeC  NeC’ ,  R)  =  §(NeC,  R)  5 (NeC',  R)  . 
eq  mtei none)  =  INF  . 

eq  mte  (NeC  NeC’)  =  min(mte  (NeC) ,  mte(NeC’))  . 

The  functions  5  and  mte  must  then  be  defined  on  individual  objects  and  messages,  as  ex¬ 
emplified  in  Section  6.2. 10 

The  tick  rule(s) — there  is  usually  just  one  tick  rule — then  typically  have  the  form 
crl  [ tickl  : 

{SYSTEM : Conf iguration} 

=> 

{5 (SYSTEM: Conf iguration,  R:Time)}  in  time  R:Time 
if  R:Time  <=  m/e(SYSTEM:Configuration)  [nonexec]  . 

The  instantaneous  rewrite  rules,  i.e.,  all  rules  except  the  tick  rule(s),  are  defined  exactly  as 
in  untimed  rewriting  logic. 

10  The  functions  8  and  mte  are  not  predefined  in  Real-Time  Maude.  They  must  be  declared  and  defined  by 
the  user. 
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4.2  Formal  Analysis  in  Real-Time  Maude 

Our  tool  translates  a  timed  module  into  an  untimed  module  which  can  be  executed  in  Maude. 
However,  the  following  reasons  indicate  that  it  is  useful  to  go  beyond  Maude’s  standard 
rewriting,  search,  and  model  checking  capabilities  to  execute  and  analyze  timed  modules: 

-  Tick  rules  are  typically  time-nondeterministic  and  cannot  be  executed  directly  in  Maude. 

-  It  is  often  more  natural  to  measure  and  control  the  rewriting  by  the  total  duration  of  a 
computation  than  by  the  number  of  rewrites  performed. 

-  Search  and  temporal  logic  properties  often  involve  the  duration  of  a  computation  (e.g., 
is  a  certain  state  always  reached  within  time  r?  is  there  a  potential  deadlock  in  the  time 
interval  [r,r')?). 

-  One  natural  way  of  reducing  the  reachable  state  space  from  an  infinite  set  to  a  finite 
set  for  model  checking  purposes  is  to  consider  only  all  behaviors  up  to  a  certain  time 
bound  r. 

In  Section  4.2.1  we  describe  the  tool’s  time  sampling  strategies,  which  guide  the  appli¬ 
cation  of  time-nondeterministic  tick  rules.  Section  4.2.2  gives  an  overview  of  the  analysis 
commands  available  in  Real-Time  Maude.  These  commands  are  timed  versions  of  Maude's 
rewriting,  search,  and  model  checking  commands.  To  achieve  high  performance,  our  tool 
executes  Real-Time  Maude  commands  by  transforming  a  timed  module  and  command  into 
an  ordinary  Maude  module  and  command  which  is  then  executed  in  Maude  as  explained  in 
Section  5. 

4.2.1  Time  Sampling  Strategies 

The  issue  of  treating  admissible  time-nondeterministic  tick  rules  is  closely  related  to  the 
treatment  of  dense  time.  The  decidable  timed  automaton  formalism  [3]  “discretizes”  dense 
time  by  defining  “clock  regions,”  so  that  all  states  in  the  same  clock  region  are  bisimilar  and 
satisfy  the  same  properties  [3].  The  clock  region  construction  is  possible  due  to  the  restric¬ 
tions  in  the  timed  automaton  formalism,  but  in  general  it  cannot  be  employed  in  the  more 
complex  systems  expressible  in  Real-Time  Maude.  Our  tool  instead  deals  with  admissible 
time-nondeterministic  tick  rules  by  offering  a  choice  of  different  “time  sampling”  strategies, 
so  that  instead  of  covering  the  whole  time  domain,  only  some  moments  are  visited. 

The  Real-Time  Maude  command 

(set  tick  def  r  .) 

for  r  a  ground  term  of  sort  Time  in  the  “current"  module,  sets  the  time  sampling  strategy  to 
the  default  mode,  which  means  that  each  application  of  a  time-nondeterministic  tick  rule  will 
try  to  advance  time  by  r  time  units.  (If  the  tick  rule  has  the  form  (f ),  then  the  time  advance 
is  the  minimum  of  u  and  r .)  The  command  (set  tick  max  . )  can  be  used  when  all  time- 
nondeterministic  tick  rules  have  the  form  (f)  to  set  a  time  sampling  strategy  which  advances 
time  by  the  largest  possible  amount,  namely  u.  The  command  (set  tick  max  def  r  .) 
sets  the  time  sampling  strategy  to  advance  time  by  the  maximum  possible  time  elapse  u 
in  rules  of  the  form  (f)  (unless  u  equals  INF),  and  tries  to  advance  time  by  r  time  units 
in  tick  rules  having  other  forms.  The  time  sampling  strategy  stays  unchanged  until  another 
strategy  is  selected  by  the  user.  Initially  it  is  set  to  deterministic  (det)  mode,  in  which  case 
it  is  assumed  that  all  tick  rules  are  time-deterministic. 

All  applications  of  time-nondeterministic  tick  rules — be  it  for  rewriting,  search,  or  model 
checking — are  performed  using  the  current  time  sampling  strategy.  This  means  that  some 
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behaviors  in  the  system,  namely  those  obtained  by  applying  the  tick  rules  differently,  are 
not  analyzed.  The  results  of  Real-Time  Maude  analysis  should  be  understood  as  being  in 
general  incomplete:  counterexamples  are  true  counterexamples,  but  (except  for  the  case  of 
discrete  time  when  all  states  are  visited)  satisfaction  of  a  property  only  shows  that  it  holds  for 
the  states  visited.  We  are  currently  working  on  identifying  classes  of  real-time  systems  and 
system  properties  for  which  a  given  time  sampling  strategy  actually  preserves  the  relevant 
system  properties  and  therefore  provides  a  complete  method  of  analysis. 


4.2.2  Real-Time  Maude  Analysis 

The  timed  rewrite  command 

(trew  [n]  in  mod  :  to  in  time  <=  r  . ) 

simulates  (at  most  n  rewrite  steps  of)  one  behavior  of  the  system,  specified  by  the  timed 
module  mod,  from  initial  state  to  (of  sort  GlobalSystem)  up  to  a  total  duration  less  than 
or  equal  to  the  Time  value  r.  The  time  bound  can  also  have  the  forms  in  time  <  r  and 
with  no  time  limit.  The  timed  fair  rewrite  (tfrew)  command  applies  the  rules  in  a  position- 
fair  and  rule-fair  way.  The  ’  [71]  ’  and  ’in  mod  :  ’  parts  of  the  command  are  optional.  Real- 
Time  Maude’s  tracing  facilities  allow  us  to  trace  the  steps  in  a  timed  rewrite  sequence 
(see  [24]  for  details). 

The  timed  search  command  can  be  used  to  analyze  not  just  one  behavior,  but  to  ana¬ 
lyze  all  behaviors  from  a  given  initial  state,  relative  to  the  chosen  time  sampling  strategy. 
This  command  extends  Maude’s  search  command  to  search  for  states  which  match  a  search 
pattern  and  which  are  reachable  in  a  given  time  interval.  The  syntax  variations  of  the  timed 
search  command  are: 

(tsearch  to  arrow  pattern  with  no  time  limit  .) 

(tsearch  to  arrow  pattern  in  time  ~  r  .) 

(tsearch  to  arrow  pattern  in  time-interval  between  r  and  ~  r  .) 

where  to  is  a  ground  term  of  sort  GlobalSystem,  pattern  is  either  t  or  has  the  form  t  such 

that  cond  for  a  ground  irreducible11  term  t  of  sort  GlobalSystem  and  a  semantic  condition 
cond  on  the  variables  occurring  in  t,  ~  is  either  <,  <=,  >,  or  >=,  is  either  >=  or  >,  is 
either  <=  or  <,  and  r  and  r'  are  ground  terms  of  sort  Time.  The  arrow  is  the  same  as  in  Maude, 
where  =>1,  =>*,  and  =>+  search  for  states  reachable  from  to  in,  respectively,  one,  zero  or 
more,  and  one  or  more  rewrite  steps.  The  arrow  => !  is  used  to  search  for  “deadlocked” 
states,  i.e.,  states  which  cannot  be  further  rewritten.  The  timed  search  command  can  be 
parameterized  by  the  number  of  solutions  sought  and/or  by  the  module  to  be  analyzed. 

Real-Time  Maude  also  has  commands  which  search  for  the  earliest  time  and  the  latest 
time  at  which  a  state  satisfying  the  desired  pattern  can  be  reached.  These  commands  are 
written  with  syntax 

(find  earliest  to  =>*  pattern  .) 

(find  latest  to  =>*  pattern  timeBound  .) 

1 1  A  term  t  is  ground  irreducible  if  and  only  if  for  all  ground  substitutions  a  such  that,  for  each  variable 
x,  the  ground  term  a(x)  is  irreducible  (using  the  equations  in  the  specification),  then  the  term  a (t)  is  itself 
irreducible. 
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We  can  also  analyze  all  behaviors  of  a  system  from  a  given  initial  state,  relative  to  the 
chosen  time  sampling  strategy,  using  Real-Time  Maude’s  time-bounded  explicit-state  lin¬ 
ear  temporal  logic  model  checker.  Such  model  checking  extends  Maude’s  high  performance 
model  checker  [14]  by  analyzing  the  rewrite  sequences  only  up  to  a  given  time  bound.  Tem¬ 
poral  formulas  are  formed  exactly  as  in  Maude,  that  is,  as  terms  of  sort  Formula  constructed 
by  user-defined  atomic  propositions  and  operators  such  as  /\  (conjunction),  \/  (disjunc¬ 
tion),  ->  (implication),  ~  (negation),  []  (“always”),  <>  (“eventually”),  U  (“until”),  =>  (“al¬ 
ways  implies”),  etc.  Atomic  propositions,  possibly  parameterized,  are  terms  of  sort  Prop 
and  their  semantics  is  defined  by  stating  for  which  states  a  property  holds.  Propositions  may 
be  clocked,  in  that  they  also  take  the  elapsed  time  into  account.  That  is,  whether  a  clocked 
proposition  holds  for  a  certain  state  depends  not  only  on  the  state,  but  also  on  the  total  du¬ 
ration  of  the  rewrite  sequence  leading  up  to  the  state.  The  proposition  clockEqualsTime 
on  page  27  shows  an  example  of  a  clocked  proposition.  A  module  defining  the  propositions 
should  import  the  predefined  module  TIMED-MODEL-CHECKER  and  the  timed  module  to  be 
analyzed.  A  formula  represents  an  untimed  linear  temporal  logic  formula;  it  is  not  a  for¬ 
mula  in  metric  temporal  logic  or  some  other  real-time  temporal  logic  [4].  The  syntax  of  the 
time-bounded  model  checking  command  is 

(me  to  |=t  formula  in  time  <=  r  . ) 

or  with  time  bounds  of  the  form  <  r  or  with  no  time  limit.  The  model  checker  in  gen¬ 
eral  cannot  prove  a  formula  correct  in  the  presence  of  time-nondeterministic  tick  rules,  since 
it  then  only  analyzes  a  subset  of  all  possible  behaviors.  However,  if  the  tool  finds  a  coun¬ 
terexample,  it  is  a  valid  counterexample  which  proves  that  the  formula  does  not  hold.  Time- 
bounded  model  checking  is  guaranteed  to  terminate  for  discrete  time  domains  when  the 
instantaneous  rules  terminate. 

The  set  of  states  reachable  from  an  initial  state  in  a  timed  module  may  well  be  finite, 
in  which  case  search  and  model  checking  should  terminate.  However,  the  internal  repre¬ 
sentation  of  a  timed  module  described  in  Section  5  adds  a  clock  component  to  each  state, 
which  makes  the  reachable  “clocked  state”  space  infinite,  unless  the  specification  is  ter¬ 
minating.  Real-Time  Maude  therefore  also  provides  untimecl  search  (syntax  (utsearch  to 
arrow  pattern  . ) )  and  untimed  model  checking  (syntax  (me  to  I  =u  formula  . ) )  where  the 
internal  representation  used  for  the  execution  does  not  add  a  clock,  and  therefore  preserves 
the  finiteness  of  the  reachable  state  space. 

Real-Time  Maude  also  has  commands  for  checking  “until”  properties  (syntax  (check  to 
1=  patterni  until  patterns  timeBound  .))  and  “until/stable”  properties  (syntax  (check 
to  |=  patterni  untilStable  patten 12  timeBound  .)).  While  the  properties  that  can  be 
expressed  by  these  commands  are  a  restricted  (but  often  useful)  subset  of  those  expressible 
in  temporal  logic,  the  check  commands  are  implemented  using  breadth-first  search  tech¬ 
niques,  and  can  therefore  sometimes  decide  properties — without  restricting  the  duration  of 
the  behaviors — for  which  temporal  logic  model  checking  does  not  terminate. 

Finally,  the  user  can  define  his/her  own  specific  analysis  and  verification  strategies  using 
Real-Time  Maude’s  reflective  capabilities  to  further  analyze  a  timed  module.  The  predefined 
module  TIMED-META-LEVEL  extends  Maude’s  META-LEVEL  module  with  the  functionality 
needed  to  execute  timed  modules  and  can  be  used  for  these  purposes. 

4.3  Expressiveness  and  Limitations  of  Real-Time  Maude 

As  mentioned  in  the  introduction,  our  tool  emphasizes  ease  and  generality  of  specification, 
so  that  large  and  complex  systems  involving,  e.g.,  different  data  types  and  forms  of  commu- 
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nication,  can  be  modeled  without  having  to  resort  to  tricky  encodings  or  imposing  limitations 
on  the  system  to  be  modeled.  To  support  this  claim,  we  showed  in  [28]  that  a  wide  range  of 
models  of  real-time  and  hybrid  systems,  including  timed  [3]  and  hybrid  automata  [2],  timed 
Petri  nets  [1],  and  timed  and  phase  transition  systems  [21],  can  all  be  naturally  expressed  as 
real-time  rewrite  theories.  In  addition,  Real-Time  Maude  supports  the  definition  of  any  com¬ 
putable  data  type,  as  well  as  advanced  object-oriented  specification  features  such  as  multiple 
inheritance  and  creation/deletion  of  objects  and  messages.  Real-Time  Maude  does  not  come 
with  built-in  communication  primitives;  instead,  the  user  can  define  her  own  form(s)  of  com¬ 
munication  at  the  desired  level  of  abstraction,  without  having  to  encode  them  using  a  given 
set  of  basic  primitives.  This  has  allowed  us  to  model  unicast  message  passing  with  different 
transmission  times  (see,  e.g..  Section  6.2)  and  more  advanced  communication  forms  such 
as  multicast  (with  appropriate  transmission  times)  through  links  [29]  and  geographically 
bounded  broadcast  in  wireless  sensor  network  systems  [30].  In  terms  of  expressiveness, 
Real-Time  Maude  stands  in  stark  contrast  not  only  to  the  timed  and  hybrid  automata,  but 
also  to  other  formalisms  and  tools,  such  as  the  real-time  models  mentioned  above,  network 
simulation  tools,  and  the  IF  toolset  [6],  Despite  this  flexibility,  our  formalism — consisting 
of  equations  and  term  rewrite  rules — is  simple  and  intuitive  and  has  a  well-defined  and  easy 
to  understand  semantics  [28]. 

Given  the  expressiveness  of  Real-Time  Maude,  it  is  no  surprise  that  most  system  proper¬ 
ties  are  in  general  undecidable.  This  is  different  from,  e.g.,  timed  automata,  whose  formalism 
is  restricted  so  that  crucial  properties  remain  decidable.  Nevertheless,  for  discrete  time — 
all  our  larger  Real-Time  Maude  applications  have  had  discrete  time  domain — Real-Time 
Maude  search  and  LTL  model  checking  can  often  be  used  to  analyze  all  possible  behav¬ 
iors  up  to  a  given  duration  from  a  given  initial  state,  thus  becoming  decision  procedures.  For 
dense  time,  however,  our  tool  only  offers  a  set  of  time  sampling  strategies,  and,  as  mentioned 
in  Section  4.2.1,  there  is  no  guarantee  that  Real-Time  Maude  search  and  model  checking  are 
“complete”  in  these  cases.  Such  analyses  cannot  be  used  to  prove  that  some  property  holds 
for  all  behaviors.  They  should  instead  be  seen  as  analyzing  a  number  of  behaviors  for  the 
purpose  of  finding  errors  or  to  strengthen  our  confidence  in  the  specification. 

We  can  summarize  the  differences  between  Real-Time  Maude  and  well-known  timed 
automaton-based  tools,  such  as  UPPAAL  [19,5]  and  Kronos  [32],  as  follows:  Many  large 
and  complex  systems  can  be  naturally  modeled  in  Real-Time  Maude  but  not  in  UPPAAL  or 
Kronos.  This  applies  to  the  Real-Time  Maude  applications  listed  in  Section  6.4,  but  also 
to  the  smaller  examples  in  Sections  6.2  and  6.3.  In  Section  6.2,  there  is  no  bound  on  the 
number  of  messages  that  can  appear  in  the  state,  so  this  simple  system  cannot  be  modeled 
by  a  timed  or  a  hybrid  automaton.  The  example  in  Section  6.3  can  be  modeled  by  a  hybrid 
automaton,  but  due  to  the  uninitialized  “stopwatch,”  it  cannot  be  modeled  within  the  decid¬ 
able  fragments  of  hybrid  automata  [16].  However,  when  timed  automaton-based  tools  can 
be  applied,  they  provide  the  following  advantages  over  Real-Time  Maude: 

-  Model  checking12  of  timed  automata  is  guaranteed  to  terminate,  while  the  corresponding 
Maude  analysis  may  fail  to  do  so. 

-  UPPAAL,  in  particular,  is  a  very  efficient  model  checking  tool  for  timed  automata,  where 
sets  of  clock  valuations  are  represented  symbolically.  Real-Time  Maude,  which  is  not 
optimized  for  the  special  case  of  timed  automata,  uses  explicit-state  search  and  model 
checking. 

12  UPPAAL’s  query  language  is  only  a  limited  subset  of  (untimed)  CTL  [5]  while  Real-Time  Maude  al¬ 
lows  us  to  define  any  propositional  linear  temporal  logic  formula.  Kronos’  query  language  is  timed  CTL 
(TCTL)  [4], 
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-  Model  checking  of  timed  automata  is  complete  also  for  dense  time. 


5  Semantics  of  Real-Time  Maude’s  Analysis  Commands 

Real-Time  Maude  is  designed  to  take  maximum  advantage  of  the  high  performance  of  the 
Maude  engine.  Most  Real-Time  Maude  analysis  commands  are  therefore  executed  by  first 
transforming  the  current  timed  module  into  a  Maude  module,  followed  by  the  execution  of 
a  corresponding  Maude  command  (at  the  Maude  meta-level).  The  actual  transformation  of  a 
timed  module  depends  on  the  Real-Time  Maude  command  to  execute.  This  section  defines 
the  semantics  of  Real-Time  Maude’s  analysis  commands  in  two  ways  by  providing: 

-  an  “abstract”  semantics,  which  specifies  requirements  for  each  command;  and 

-  a  concrete  “Maude  semantics,”  which  defines  the  semantics  of  a  Real-Time  Maude  com¬ 
mand  as  the  theory  transformation  and  Maude  command  used  to  execute  it. 

In  what  follows  we  show  how  the  concrete  semantics  satisfies  the  abstract  one.  The  concrete 
“Maude  semantics”  adopts  a  reductionistic  approach  based  on  semantics-preserving  theory 
transformations.  As  explained  in  Section  5.1,  any  real-time  rewrite  theory  can  be  trans¬ 
formed  into  a  semantically  equivalent  ordinary  rewrite  theory.  This  fact  is  systematically 
exploited  in  our  concrete  “Maude  semantics,”  to  internally  transform  real-time  commands 
into  ordinary  Maude  commands.  The  subtle  point,  however,  is  that,  as  we  explain  for  each 
command,  the  Real-Time  Maude  module  and  command  must  be  transformed  together  into  a 
corresponding  Maude  module  and  command.  This  is  because  the  command  itself  places  ad¬ 
ditional  constraints,  due  to,  e.g.,  the  specified  time  bound  or  the  time  sampling  strategy,  that 
must  be  reflected  in  the  transformed  theory.  For  example,  the  transformed  tick  rule  should 
not  tick  the  time  beyond  the  time  bound  specified  in  the  command. 

Section  5.1  describes  the  “default”  transformation  of  a  real-time  rewrite  theory  into  an 
ordinary  rewrite  theory,  and  therefore  of  Real-Time  Maude  modules  into  Maude  modules. 
Section  5.2  gives  the  semantics  of  the  time  sampling  strategies.  Sections  5.4  to  5.6  present 
the  semantics  of,  respectively,  the  timed  rewrite  commands,  timed  search  and  related  com¬ 
mands,  and  time-bounded  linear  temporal  logic  model  checking.  Section  5.7  treats  Real- 
Time  Maude’s  untimed  analysis  commands. 


5.1  The  Clocked  Transformation 

Definition  2  The  clocked  transformation,  which  maps  a  real-time  rewrite  theory  Ma.j  with 
Si  =  ( E,E,(p,R )  to  an  ordinary  rewrite  theory  (Sf^,^)6'  =  (Ec  ,EC  ,(pc  ,RC),  adds  the 
declarations 

sorts  ClockedSystem  . 

subsort  GlobalSystem  <  ClockedSystem  . 

op  _in  time_  :  GlobalSystem  Time§  ->  ClockedSystem  [ctor]  . 
eq  (CLS :  ClockedSystem  in  time  R:  Time^)  in  time  R ’  :  Time,),  = 

CLS : ClockedSystem  in  time  (R :  Time,/,  +0  R’  :  Time,),)  . 

to  [E,E,  <p),  and  defines  Rc  to  be  the  union  of  the  instantaneous  rules  in  R  and  a  rule 

/:  { ty — >{.t'y  in  time  T;  if  cond 

for  each  corresponding  tick  rule  l :  { t }  it.'}  if  cond  in  R. 
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This  clocked  transformation  adds  a  clock  component  to  each  state  and  resembles  the 
transformation  (_)c'  described  in  [28],  but  is  simpler,  since  it  is  essentially  the  identity.  It  is 
worth  noticing  that  the  reachable  state  space  from  a  state  {ty  in  c  is  normally  infinite, 

even  when  the  reachable  state  space  from  {ty  is  finite  in  The  arguments  in  [28]  can 
easily  be  adapted  to  show: 

Fact  1  For  all  terms  t,  t'  of  sort  GlobalSystem  and  all  terms  r  f-  0 a,  r'  of  sort  Time §  in 

•  >^>,t  I ~t-—>t'  <i=f-  t - >  t'  in  time  r 

<i=f-  C  t  in  time  r' - >  t'  in  time  r'+^r,  and 

•  h  t — ~^t’  <i=f-  F  t  in  time  r' - *t'  in  time  r' . 

In  addition,  T  h  t  — — >  t'  <i=f-  T) c  h  t  — >  t!  holds  when  contains  only  admis¬ 

sible  tick  rules.  Moreover,  these  equivalences  hold  for  n-step  rewrites  for  all  n. 

In  Real-Time  Maude,  thanks  to  its  syntax,  this  transformation  is  performed  by  importing 
the  module  TIMED-PRELUDE,  which  contains  the  above  declarations  (with  Time  for  Timeq,, 
etc.),  and  by  leaving  the  rest  of  the  specification  unchanged.  Real-Time  Maude  internally 
stores  a  timed  module  by  means  of  its  clocked  representation.  All  Full  Maude  commands 
extend  to  Real-Time  Maude  and  execute  this  clocked  representation  of  the  current  timed 
module.  Fact  1  justifies  this  choice  of  execution. 


5.2  Time  Sampling  Strategies 

Definition  3  The  set  tss(f%^^)  of  time  sampling  strategies  associated  with  the  real-time 
rewrite  theory  with  1%  =  (E,E,cp,  R)  is  defined  by 

tes(^,T)  =  {def(r)  \  r  E  TL  T.imeil>}U{max}U{maxDef(r)  \  r  E  TLTmeip}U{det}. 

In  Real-Time  Maude,  these  time  sampling  strategies  are  “set”  with  the  respective  com¬ 
mands  (set  tick  def  r  .),  (set  tick  max  .),  (set  tick  max  def  r  .),and 
(set  tick  det  .). 

Definition  4  For  each  s  E  tss{Mq^),  the  mapping  which  takes  the  real-time  rewrite  theory 
to  the  real-time  rewrite  theory  Sfi  r  in  which  the  admissible  time-nondeterministic 
tick  rules  are  applied  according  to  the  time  sampling  strategy  s,  is  defined  as  follows: 

x-Ti  def(r) 

-  Sf  j,  T  equals  ^jT,  with  the  admissible  time-nondeterministic  tick  rules  of  the  forms 
(t),  (t),  (*),  and  (§)  in  Section  4. 1.2  replaced  by,  respectively,  the  following  tick  rules13: 

-  I  :  {ty  -—>■  { t'y  if  cond  A  x  :=  if  ( u  <a  r)  then  u  else  r  f  i  A  x  <q  u  A  cond! 

-  I :  ft}  — ^  {t'y  if  x  :=  r  A  cond  A  x  <$  u  A  cond1 

-  I :  ft}  {t'y  if  x  :=  r  A  cond 

-  I :  {ty^{t'y  if  x  :=  r 

13  The  Real-Time  Maude  tool  assumes  the  modified  tick  rules  to  be  executable,  and  therefore  "removes” 
their  nonexec  attributes.  The  syntax  v  :=  w  is  that  of  Maude  for  "matching  equations”  [10],  where  the 
ground-irreducible  pattern  v  (in  the  above  rules  v  is  just  the  variable  x)  is  matched  against  the  result  of 
evaluating  w. 
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If  the  time  domain  is  linear,  so  that  <j)  can  be  extended  to  the  theory  LTIME  [28],  the 
first  of  the  above  rules  can  be  given  in  the  simpler  form 

l :  if  cond  Ai:=  min^{ u,r)  A  cond! . 

-  is  S%tp^  with  each  rule  of  the  form  (f)  replaced  by  the  rule 

i:  m^u'y  if  cond  Ai:=uA  cond' 

(and  with  the  other  tick  rules  left  unchanged).  Notice  that  the  condition  does  not  hold  if 
u  evaluates  to  the  infinity  value. 

-  <%™®xDef(r^  equals  *  with  each  (f)-rule  replaced  by  the  rule 

l  :  ity  — —>  {.t'y  if  cond  A  x  :=  if  u  :  Time<f>  then  u  else  r  f  i  A  x  <<j,  u  A  cond' . 

_  apdet  _  ap 

Real-Time  Maude  implements  these  transformations,  with  le  for  <^,  etc.  We  do  not 
assume  that  the  time  domain  is  linear.  By  the  current  time  sampling  strategy  we  mean  the 
time  sampling  strategy  defined  by  the  last  set  tick  command  given,  and  we  assume  that 
any  time  value  used  in  the  last  set  tick  command  is  a  time  value  in  the  “current”  module. 

The  set  of  rewrites  using  a  particular  time  sampling  strategy  is  a  subset  of  all  possible 
rewrites: 

Fact  2  For  each  s  6  tss(M^tz)>  r  b  t  — >  t'  implies  b  t  t'  for  all  terms  t ,  t'  of 
sort  GlobalSystem,  and  all  ground  terms  r  of  sort  Time Furthermore,  this  property  holds 
for  all  n-step  rewrites. 


5.3  Tick  Rules  with  zero  Time  Advance 

Real-Time  Maude  does  not  apply  a  tick  rule  when  time  would  advance  by  an  amount  equal 
to  zero.  This  is  a  pragmatic  choice  based  on  the  fact  that  advancing  time  by  zero  using 
admissible  tick  rules  does  not  change  the  state,  but  leads  to  unnecessary  looping  during 
executions.  We  denote  by  the  real-time  rewrite  theory  obtained  from  .^  T  by  adding 
the  condition  T;  ^  0^  to  each  tick  rule.  We  write  BSi ’™2  for  T)nz . 

Fact  3  ^  ^  t'  implies  b  t  t'.  The  implication  extends  to  rewrites  of  length 

nfor  any  n,  and  is  an  equivalence  for  specifications  with  only  admissible  tick  rules. 


5.4  Timed  Rewriting 

The  timed  rewrite  command 

(trew  [n]  in  :  t  with  no  time  limit  .), 

for  t  a  term  of  sort  GlobalSystem,  returns  a  term  t'  such  that 

-  ,^  T  b  t  — *  t!  is  a  rewrite  in  at  most  n  steps,  and 

-  t'  cannot  be  further  rewritten  in  ’™z  (for  s  the  current  time  sampling  strategy)  unless 
t  — >  t'  is  a  rewrite  in  exactly  n  steps. 
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This  command  is  executed  at  the  Maude  meta-level  by  (a  call  to  a  built-in  function 
equivalent  to)  executing  the  Maude  command 

rewrite  [n]  in  :  t  . 

for  s  the  current  time  sampling  strategy.  The  correctness  of  executing  the  timed  command 
in  this  way  follows  from  the  fact  that  if  the  result  is  a  term  t'  in  time  r,  then  G  h 

t - >t'  in  time  r,  and  we  have  ( [S?f™z)G  l~  f - >  t'  in  time  r  =>  S£sf™z  h 

=>  h  t  — t' .  All  implications  preserve  the  number  of  rewrite  steps.  Finally,  it  also 
follows  from  Fact  1  that  t!  cannot  be  rewritten  further  in  Ml’xz  if  t'  in  time  r  cannot  be 
rewritten  in  .  The  correctness  argument  is  analogous  if  the  result  of  the  rewrite 

command  is  a  GlobalSystem  term  t! . 

Let  ~  stand  for  either  <=  or  <,  and  let  <=^  and  <4,  stand  for  <4,  and  <§.  The  time- 
bounded  rewrite  command 

(trew  [n]  in  :  t  in  time  ~  r  .), 

again  for  t  a  term  of  sort  GlobalSystem,  returns  a  term  t'  such  that 

r' 

-  S#$.x  h  t  — *  t ,  for  r'  r,  is  a  rewrite  in  at  most  n  steps,  and 

-  either  t  — >  t'  is  an  n-step  rewrite,  or  there  is  no  t"  such  that  Sit’™"  h  t'  t"  for 
r'+<l>  r- 

To  execute  time-bounded  rewrite  commands  we  use  a  different  transformation  of  a  real¬ 
time  rewrite  theory  which  ensures  that  the  clocks  associated  to  the  states  never  go  beyond 
the  time  limit. 

Definitions  Let  M§_x  be  a  real-time  rewrite  theory  with  Si  =  ( E,E,(p,R ),  and  let  r  £ 
Tx.Time^-  The  mapping  which  takes  Si§x  to  the  rewrite  theory  =  (EB  ,EB ,  (pB ,R-r) 

is  defined  as  follows: 

-  EB  =  Ec  U{[_]  :  ClockedSystem — >  ClockedSystem }14, 

-  Eb  =  Ec, 

-  tpB  extends  <p  so  that  (pB  ([_])=  0,  and 

-  R-r  is  the  union  of  the  instantaneous  rules  in  Sip.x  and  a  rule 

l  :  [{t>  in  time  y ]  — >  Lit1}  in  time  T;  y\  if  cond  AT i  +<j>  y  <<p  r 

for  each  tick  rule  l  :  it}  — » it  }  if  cond  in  Si§:X,  where  y  is  a  variable  of  sort  Time $ 
which  does  not  occur  in  the  original  tick  rule. 

Fact  4 

-  For  all  r,  r"  with  r"  r'  <i>  t,  we  have  that  Si&^  h  t - >  t  if  and  only  if  (S$t,)X)-r  h 

Lt  in  time  r"~\  — *  Lt'  in  time  r"  +0  r'~\ .  In  addition,  the  number  of  rewrite  steps 
are  the  same  in  both  sides  of  the  equivalence. 

-  (&d,.z)-r  Lt  in  time  r']  — >t"  and  r'  <a  r  implies  that  t"  is  a  term  of  the  form 
Lt'  in  time  r"\  with  r"  <0  r.  That  is,  it  is  not  possible  to  rewrite  beyond  the  time 
limit. 


14 


The  operator  [  ]  is  called  global  in  the  current  implementation  of  the  tool. 
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Real-Time  Maude  executes  the  time-bounded  rewrite  command 
(trew  [n]  in  :  t  in  time  <=  r  . ) 

by  executing  the  command  rewrite  [n]  in  {Ml’™z)-r  :  [t  in  time  0^]  .  in  Maude. 

For  the  correctness  argument,  it  follows  from  Fact  4  that  the  result  is  [l1  in  time  /] 
for  some  r'  <a  r  since  0  a  r.  By  the  first  part  of  that  fact,  it  follows  that  (since  r'  = 

0 ^  r')  Ml’™z  b  t  t',  which  implies  b  t  t'.  Finally,  it  also  follows  from  Fact  4 

r" 

that  there  is  no  nontrivial  rewrite  t!  — *  t"  with  r1  r"  <<f,  r  in  Ml’™z  if  It1  in  time  r'] 
cannot  be  further  rewritten  in  (Ml’™z)-r. 

The  execution  of  a  timed  rewrite  command  with  a  time  bound  of  the  form  <  r  is  entirely 
analogous,  with  each  occurrence  of  the  symbol  <  replaced  by  the  symbol  <. 


5.5  Timed  Search 


The  timed  search  command 


(tsearch  [n]  in  :  to  =>*  t  such  that  cond 

in  time-interval  between  ~  r  and  r/  .) 

r" 

should  return  at  most  n  substitutions  a  satisfying  cond  such  that  b  to — for 
r"  r  and  r"  r1 .  It  is  executed  as  the  Maude  command 

search  [n]  in  : 

[to  in  time  0^]  =>*  [ t  in  time  TIME-ELAPSED] 
such  that  cond  /\  TIME-ELAPSED  r  . 


for  s  the  current  time  sampling  strategy,  and  TIME-ELAPSED  a  variable  of  sort  Time q  which 
does  not  occur  in  t  (otherwise  a  variable  TIME-ELAPSED#  1  is  used). 

For  correctness,  if  a  is  a  solution,  then  r  F  [to  in  time  0^]  - > 

[cr(f)  in  time  ct(TIME-ELAPSED)]  .  By  Fact  4,  CT (TIME-ELAPSED)  r  and 


h  to 


tr(TIME-ELAPSED) 


a(t),  and  therefore 


h  to 


ct(TIME-ELAPSED) 


o{t).  Finally, 


the  such  that  condition  implies  that  CT(TIME-ELAPSED)  ^  r. 

Real-Time  Maude  allows  the  term  t  in  the  search  pattern  to  have  the  form  t'  in  time  t" , 
which  is  useful  for  searching  for  states  matching  patterns  such  as  t(x)  in  time  x.  Such 
patterns  are  treated  by  replacing  TIME-ELAPSED  with  t". 

Since  all  the  facts  used  in  the  argumentation  preserve  the  number  of  rewrite  steps,  the 
same  translation  can  be  used  with  the  arrows  =>1  and  =>+  instead  of  =>*. 

It  is  worth  remarking  that 


-  the  search  will  return  (at  most)  n  substitutions  on  the  domain  vars(t)  U  {TIME-ELAPSED}, 
which  do  not  necessarily  correspond  to  n  distinct  substitutions  when  restricted  to  vars(t); 

-  the  search  will  terminate  if  the  time  domain  is  discrete  (or  the  time  sampling  strategy  s 
makes  ^f’"2  “non-Zeno”),  and  the  instantaneous  rules  terminate; 

r n 

-  solutions  a  with  ,^  T  b  to — »<r(f)  can  be  missed  because  it  may  be  that  Ml’™*  jb 

r" 

to — >a(t). 


The  time-bounded  search  command  for  deadlocks 
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(tsearch  [n]  in  :  £o  => !  t  such  that  cond 

in  time-interval  between  ~  r  and  r/  .) 

r" 

searches  for  substitutions  <7  satisfying  cond  such  that  ,^  T  b  to  — >  <y(t)  for  r"  r  and 
t"  r',  and  such  that  cr(t)  cannot  be  further  rewritten  in  The  translation 

cannot  be  used  since  it  would  give  deadlocks  at  all  states  which  cannot  be  further  rewritten 
within  the  time  bound. 

The  following  translation  is  used  instead  for  searching  for  deadlocks.  It  adds  a  self-loop 
whenever  a  tick  rule  could  advance  the  total  time  elapse  of  a  computation  beyond  the  time 
limit. 

Definition  6  Let  -M§.x  be  a  real-time  rewrite  theory  with  £%  =  (E.E.tp.R),  and  let  r  G 
T r.Time^-  The  mapping  which  takes  to  the  rewrite  theory  is  defined  by 

z)~r  =  (Ls,  EB ,  (pB ,  R-r),  where  R-r  is  the  union  of  the  instantaneous  rules  in 
and  a  rule 

l  :  [{£}  in  time  y\ - >  if  (ti +<p  y  r)  then  [{£'}  in  time  T i+tpy] 

else  [{£}  in  time  y\  f  i  if  cond 

for  each  tick  rule  l :  it}  it1}  if  cond  in  M§.x,  where  y  is  a  variable  of  sort  Time §  which 
does  not  occur  in  the  original  tick  rule. 

The  transformation  is  defined  in  the  same  way. 

Since  only  modifies  by  adding  trivial  rewrites,  most  of  Fact  4  also 

holds  in  (M$.x)-r .  Moreover,  since  the  instantaneous  rules  are  unchanged,  and  since  for 
each  tick  rule  which  can  be  applied  in  ^jT,  the  corresponding  rule  can  be  applied  to  a 
corresponding  state  in  (^,T)-r,  it  follows  that  a  term  can  be  rewritten  in  Mq,.x  if  and  only 
if  it  can  be  rewritten  in  (,^  t)-r: 

Fact  5 

r'  5- 

-  For  all  r  ,  r"  with  r'+i*  r'  r  it  is  the  case  that&A^  b  t  — >  t'  if  and  only  if(f%$,f)-r  b 
[£  in  time  r']  — >  It1  in  time  r"  +0  r].  In  addition,  the  number  of  rewrite  steps 
can  be  preser\’ed  by  the  translation. 

-  (&d>, x)-r  b  [£  in  time  r')  — >  t"  and  r'  <,*  r  imply  that  t"  is  ( equivalent  to)  a  term 
of  the  form  \_t'  in  time  ri  with  r"  <  ^  r.  That  is,  it  is  not  possible  to  rewrite  beyond 
the  time  limit. 

r' 

-  If&<j),x  b  t - *  t'  is  a  one-step  rewrite,  and  r"  <a  r  and  -> {r  r'  <a  r),  then  there  is 

a  one-step  “identity”  rewrite  (3% U ,%)-r  b  [£  in  time  r"\  — >  [£  in  time  r"\. 

The  above  timed  search  command  for  deadlocks  is  interpreted  by  the  Maude  command 

search  [n]  in  : 

[to  in  time  0^]  => !  [£  in  time  TIME-ELAPSED] 

such  that  cond  /\  TIME-ELAPSED  r  . 

To  see  that  each  solution  a  is  really  a  deadlocking’"",  assume  that^f’""  b  a(t)  —>  t' 
in  one  step.  It  follows  from  Fact  5  that,  depending  on  whether  r"  +4,  r'  r,  the  term 
[CT(i)  in  time  r"\  rewrites  either  to  \_t'  in  time  r"  +</>  r']  or  to  [<7(i)  in  time  r"\  in 

one  step  in  [3#TZ  ) 
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It  is  worth  noticing  that  a  deadlock  in  does  not  necessarily  correspond  to  a  dead¬ 

lock  in  Mq.x,  and  that  a  deadlock  in  ,^  T  may  not  necessarily  be  reached  in 

For  search  commands  with  simpler  time  bounds,  a  command  (tsearch  to  arrow  t 
such  that  cond  in  time  ~  r  . )  is  equivalent  to  (tsearch  to  arrow  t  such  that 
cond  in  time-interval  between  >=  0^,  and  ~  r  . )  for  ~  either  <=  or  <.  If  ~  is  either 
>=  or  >,  the  above  search  command  is  interpreted  by  the  Maude  command 

search  [n]  in  )c  :  to  arrow  t  in  time  TIME-ELAPSED 

such  that  cond  /\  TIME-ELAPSED  r  . 

A  timed  search  command  with  bound 'with  no  time  limit’ is  the  same  as  the  correspond¬ 
ing  search  command  with  time  bound  >=  0,j, . 


5.6  Time-Bounded  Temporal  Logic  Model  Checking 

What  is  the  meaning  of  the  time-bounded  liveness  property  “the  clock  value  will  always 
reach  the  value  24  within  time  24”  in  the  following  specification? 

(tmod  CLOCK  is  protecting  POSRAT-TIME-DOMAIN  . 
op  clock  :  Time  ->  System  [ctor]  . 
vars  R  R’  :  Time  . 

rl  [tick]  :  {clock(R)}  =>  {clock(R  +  R’)}  in  time  R’  [nonexec]  . 
endtm) 

Real-Time  Maude  does  not  assume  that  time  24  must  be  "visited”  when  model  checking  a 
property  “within  time  24.”  Such  an  assumption  would  make  the  above  property  hold  within 
time  24  but  not  within  time  25,  and  an  ordinary  simulation  would  not  necessarily  reach  the 
desired  state,  which  is  counterintuitive  if  we  have  proved  that  the  desired  state  is  always 
reached  within  time  24.  Instead,  time-bounded  linear  temporal  logic  formulas  will  be  inter¬ 
preted  over  all  possible  paths,  “chopped  off”  at  the  time  limit: 

Definition  7  Given  a  real-time  rewrite  theory  ^jT,  a  term  to  of  sort  GlobalSystem,  and  a 
ground  term  r  of  sort  Time^,  the  set  Paths(M is  the  set  of  all  infinite  sequences 

Tt=  ([to  in  time  no]  — >  [it  in  time  n]  — > - >  [U  in  time  ry] - >  •  •  •) 

of  ^  -states,  with  ro  =  O^,,  such  that  either 

r1 

-  for  all  if  i'i  r  <md  h  ti  — *  ti+ 1  is  a  one-step  sequential  rewrite  for  rt  +0  r  = 

n+ 1,  or 

-  there  exists  a  k  such  that 

-  either  there  is  a  one-step  rewrite  1“  Ifc  — >  t  with  rfc  r  and 
rk  +0  r’  ^0  r,  or 

-  there  is  no  one-step  rewrite  from  tk  in 

r ’ 

and  h  tt  — >  ti+ 1  is  a  one-step  sequential  rewrite  with  rt  +0  r  =  rl+\  for  all  i  <  k; 
and  r-j  =  and  tj  =  tk  for  all  j  >  k. 

We  denote  by  7 z(i)  the  «th  element  of  path  71. 
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That  is,  we  add  a  self-loop  for  each  deadlocked  state  reachable  within  time  r,  as  well  as 
for  each  state  which  could  tick  beyond  time  r  in  one  step,  even  when  it  could  also  rewrite 
to  something  else  within  the  time  limit. 

The  temporal  logic  properties  are  given  as  ordinary  LTL  formulas  over  a  set  of  atomic 
propositions.  We  find  it  useful  to  allow  both  state  propositions,  which  are  defined  on  terms 
of  sort  GlobalSystem,  and  clocked  propositions,  which  can  also  take  the  time  stamps  into 
account.  To  allow  clocked  propositions,  propositions  are  defined  w.r.t.  the  clocked  represen¬ 
tation  of  a  real-time  rewrite  theory  3%$^-  The  satisfaction  of  a  state  proposition 

p  S  77  is  independent  of  the  time  stamps,  so  the  labeling  function  Ln  is  extended  to  a  la¬ 
beling  Lfl  which  is  the  “smallest”  function  satisfying  Ln([t})  C  L(fj([t])  and  Ln([t'})  C 
Lfjdt'  in  time  r])  for  all  t ,  t' ,  and  r. 

In  Real-Time  Maude,  we  declare  the  atomic  (state  and  clocked)  propositions  77  (as  terms 
of  sort  Prop),  and  define  their  semantics  Ln,  in  a  module  which  imports  the  module  to  be  an¬ 
alyzed  (represented  by  its  clocked  version)  and  the  predefined  module  TIMED-MODEL-CHECKER. 
The  latter  extends  Maude’s  MODEL-CHECKER  module  with  the  subsort  declaration 

subsort  ClockedSystem  <  State  . 

Real-Time  Maude  transforms  a  module  M/Jf(  defining  77  and  Ln  into  a  module  M Lc  defining 
the  labeling  function  by  adding  the  conditional  equation 

ceq  GS : GlobalSystem  in  time  R:Time  |=  P:Prop  =  true 
if  GS : GlobalSystem  |=  P:Prop  . 

The  definition  of  the  satisfaction  relation  of  time-bounded  temporal  logic  is  given  as  follows: 

Definition  8  Given  a  real-time  rewrite  theory  a  protecting  extension  Ln  of 
defining  the  atomic  state  and  clocked  propositions  77,  an  initial  state  to  of  sort  GlobalSystem, 
a  Time<j,  value  r,  and  an  LTL  formula  <P,  we  define  the  time-bounded  satisfaction  relation 

\=<r  by 

Stf/p, t,  Ln,  k>  \=<r  <7>  if  and  only  if  Tt,  Ln  |=  <£  for  all  paths  K  G  Paths , 
where  |=  is  the  usual  definition  of  temporal  satisfaction  on  infinite  paths. 

A  time-bounded  property  which  holds  when  a  time  sampling  strategy  is  taken  into  ac¬ 
count  does  not  necessarily  hold  in  the  original  theory.  But  a  counterexample  to  a  time- 
bounded  formula  when  the  time  sampling  strategy  is  taken  into  account,  is  also  a  valid 
counterexample  in  the  original  system  if  the  time  sampling  strategy  is  different  from  det 
and  all  time-nondeterministic  tick  rules  have  the  form  (f): 

Fact  6  LetS&ty  x  be  an  admissible  real-time  rewrite  theory  where  each  time-nondeterministic 
tick  rule  has  the  form  (f)  with  u  a  term  of  sort  Time <p.  Then,  for  any  Timei,  value  r, 
term  t  of  sort  GlobalSystem,  and  s  G  tss{f%Q^)  with  s  f=-  det,  we  have  Paths(&f™z)fr  C 
Paths^tp^f1 . 

Corollary  1  For  s,  r,  and  t  as  in  Fact  6, 


Ms^z ,  Ln,  t  ty=<r  <P  implies  &<p,T,Ln,  t  ty=<r  <&■ 
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Let  S$.§.x  be  the  current  module,  Ln  a  protecting  extension  of  {M^_x)c  which  defines 
the  propositions  77,  and  let  s  be  the  current  time  sampling  strategy.  Furthermore,  let  L be 
the  protecting  extension  of  which  extends  L £  by  adding  the  equation 

\_x  in  time  y\  I  =  P  =  true  if  a:  in  time  y  \  =  P 

for  variables  x,  y,  and  P.  The  time-bounded  model  checking  command 

(me  to  |=t  <P  in  time  <=  r  . ) 

is  interpreted  by  checking  the  ordinary  LTL  satisfaction 

,  [ClockedSystem]  )  £,  [ [to  in  time  0^ ] ]  |=  ^ 

V,  Ln 

using  Maude’s  model  checker.  The  correctness  of  this  choice  is  given  by  the  following  fact: 

Fact  7 


Ln,  to  \=<r  &  if  and  only  if 

x)-r ,  [ClockedSystem]  )  q  ,  [  [to  in  time  0<* ]  ]  |=  •f' . 

Ln 

The  validity  of  this  fact  is  based  on  the  following  observations: 

-  For  each  path  [to  in  time  n>]  — >  [t\  in  time  ri] - >  ■  ■  ■  in  Paths ,r)^r  there  is 

a  corresponding  path  [  [to  in  time  ml]  — *  [Ui  in  time  ri]  j - >  ■  ■  ■  in 

T)-r,  [ClockedSystem])  £,  and  vice  versa. 

Ln 

-  £#([*  in  time  r])  =  aw  in  time  r] ])  for  all  terms  t  and  r. 

The  case  where  the  time  bound  in  a  model  checking  command  has  the  form  <  r  is 
treated  in  an  entirely  similar  way.  The  case  with  bound  no  time  limit  is  model  checked 
by  checking  whether  the  L^-property  <5  holds  in  the  rewrite  theory  (f%l'™z)c . 


5.7  Untimed  Search  and  Model  Checking 

Real-Time  Maude  also  provides  commands  for  untimed  search  and  temporal  logic  model 
checking,  which  are  particularly  useful  when  the  reachable  state  space  from  a  term  {i}  is 
finite  in  but  is  infinite  in  due  to  the  time  stamps.  The  untimed  commands  use 

the  transformation  which  takes  a  real-time  rewrite  theory  =  (L,  E,(p,R)  to  the  rewrite 
theory  =  ( E,E,(p,Ru ),  where  Ru  is  the  union  of  the  instantaneous  rules  in  R 

and  a  rule  l  :  it}  — » it'}  if  cond  for  each  tick  rule  of  the  form  l  :  it}  it'}  if  cond  in 
R.  Since  U  just  ignores  the  durations  of  tick  rules,  it  follows  that  the  one-step  rewrite 

relations  in  (,^  t) u  and  in  Mqxx  are  the  same. 

Real-Time  Maude’s  untimed  search  command,  with  syntax  (utsearch  [n]  fo  arrow 
pattern  . ) ,  and  the  untimed  model  checking  command,  with  syntax  (me  to  I  =u  <P  . ) ,  are 
executed  by  the  corresponding  commands  in  Maude  on  the  rewrite  theory  11  for  s 

the  current  time  sampling  strategy.  The  formula  <7>  should  not  contain  clocked  propositions. 
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5.8  Other  Analysis  Commands 

The  execution  of  (find  earliest  to  =>*  t  such  that  cond  . )  in  a  module  relative 

to  a  chosen  time  sampling  strategy  s,  uses  Maude’s  search  capabilities  to  return  a  term  a(t) 
in  time  r,  such  that  Ml h  to  — o{t)  for  <7  satisfying  cond,  and  such  that  there  is  no 

a'  satisfying  cond  and  r'  with  r'  <4,  r  and  Ml'™z  b  to^-^G'(t).  The  execution  of  this 
command  may  loop  if  there  is  no  such  match  a. 

The  (find  latest  to  =>*  t  such  that  cond  timeBound  .)  command  (where  time- 
Bound  is  either  with  no  time  limit,  in  time  <  r,  or  in  time  <=  r  for  some  time 
value  r)  analyzes  all  behaviors  in  Ml’™z  and  finds  the  longest  time  needed,  in  the  worst 
case,  to  reach  a  f-state  from  to-  That  is,  for  timeBound  of  the  form  <=  r,  the  command 
looks  for  a  (^  T)c-term  a(t)  in  time  r' ,  with  a  satisfying  cond ,  such  that 

-  for  each  n  G  Paths  (Mt’™*)^  there  exist  g'  (satisfying  cond),  i,  and  r"  such  that  n(i) 
equals  [g' (t)  in  time  r"]\ 

-  there  exists  a  (worst)  path  n  6  Paths(M^™z)^  and  a  number  i  such  that  n(i)  equals 
[cr(f)  in  time  r']  and  such  that  there  are  no  k  <  i,  g'  satisfying  cond,  and  r"  with 
7t(k)  =  [Gr{t)  in  time  r"\,  and 

-  for  each  path  n  6  Paths(M^z)^r ,  if  7i(i)  equals  [cr' ( i)  in  time  r"]  for  some  i,  g' 
satisfying  cond,  and  r"  with  r"  <$  r' ,  then  there  exists  a  k  <  i  such  that  7i(k)  =  [cr"(f) 
in  time  r"'\  for  some  g"  satisfying  cond  and  r'" . 

The  cases  with  timeBound  of  the  forms  <  r  and  with  no  time  limit  are  defined  in  a 
similar  way. 

For  the  check  commands,  let  pi  be  a  pattern  such  that  condi,  for  i  G  {1,2},  where 
ti  is  a  ground  irreducible  term  of  sort  GlobalSystem  or  sort  ClockedSystem.  We  can  view 
each  pi  as  a  proposition  and  can  define  the  labeling  function  L{Pi.P2 }  on  (7?0  r)c'-states  by 
Pi  6  i{pl,pT}([f])  if  and  only  if  there  exist  a  t'  6  [£]  and  a  substitution  G  satisfying  condi 
such  that  t'  =  cr(pi).  The  command  (check  to  I  =  pi  until  P2  in  time  <=  r  . )  checks  the 
until  property 

^L{PI,P2}^  N<r  P1UP2, 

and  the  command  (check  to  1=  pi  untilStable  P2  in  time  <=  r  . )  checks  whether  the 
property  P2  is  in  addition  stable,  i.e.,  it  checks  the  “until/stable”  temporal  property 

’Hpupi}’1®  H<r  (piUp2)/\(p2=>  □  Pi)- 

The  treatment  of  time  bounds  of  the  forms  <  r  and  with  no  time  limit  is  analogous. 
Notice  that  the  find  latest  command  implicitly  contains  a  check  of  the  liveness  property 
<>  pattern. 

The  find  latest  and  check  commands  are  implemented  by  breadth-first  search  strate¬ 
gies,  and  can  therefore  sometimes  decide  properties  for  which  the  temporal  logic  model 
checker  fails.  In  addition,  the  user  does  not  need  to  explicitly  define  temporal  logic  proposi¬ 
tions  for  these  commands.  On  the  minus  side,  performance  may  be  affected  by  the  fact  that 
these  commands  do  not  use  Maude’s  efficient  search  or  model  checking  facilities. 


6  Using  Real-Time  Maude 

In  this  section  we  first  illustrate  specification  and  analysis  in  Real-Time  Maude  with  a  very 
simple  example  (Section  6.1),  followed  by  a  more  interesting  example  illustrating  object- 
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oriented  specification  (Section  6.2)  and  by  a  small  hybrid  system  example  (Section  6.3). 
Finally,  Section  6.4  mentions  some  larger  Real-Time  Maude  applications. 


6.1  A  Clock  Example 

The  following  timed  module  models  a  “clock"  which  may  be  running  (in  which  case  the 
system  is  in  state  {clock  (r )  >  for  r  the  time  shown  by  the  clock)  or  which  may  have  stopped 
(in  which  case  the  system  is  in  state  {stopped-clock(r)}  for  r  the  clock  value  when  it 
stopped).  When  the  clock  shows  24  it  must  be  reset  to  0  immediately: 

(tmod  DENSE-CLOCK  is  protecting  POSRAT-TIME-DOMAIN  . 
ops  clock  stopped-clock  :  Time  ->  System  [ctor]  . 
vars  R  R’  :  Time  . 

crl  [tickWhenRunning]  :  {clock(R)}  =>  {clock(R  +  R’)}  in  time  R’ 

if  R’  <=  24  -  R  [nonexec]  . 

rl  [tickWhenStopped]  : 

{stopped-clock(R)}-  =>  {stopped-clock(R) }  in  time  R’  [nonexec]  . 
rl  [reset]  :  clock(24)  =>  clock(O)  . 

rl  [batteryDies]  :  clock(R)  =>  stopped-clock(R)  . 

endtm) 

The  two  tick  rules  model  the  effect  of  time  elapse  on  a  system  by  increasing  the  clock 
value  of  a  running  clock  according  to  the  time  elapsed,  and  by  leaving  a  stopped  clock  un¬ 
changed.  Time  may  elapse  by  any  amount  of  time  less  than  24  -  r  from  a  state  {clock(r) }, 
and  by  any  amount  of  time  from  a  state  {stopped-clock(r)}.  To  execute  the  specifica¬ 
tion  we  should  first  specify  a  time  sampling  strategy,  for  example  by  giving  the  command 
(set  tick  def  1  . ).  The  command15 

(trew  {clock(O)}-  in  time  <=99  .) 

Result  ClockedSystem  :  { stopped- clock  (2^ )}  in  time  99 

then  simulates  one  behavior  of  the  system  up  to  total  duration  99.  The  command 

(tsearch  [1]  {clock(O)}  =>*  {clock(X : Time) }  such  that  X:Time  >  24 
in  time  <=99  .) 


No  solution 

checks  whether  some  state  {clock  (r)},  with  r  >  24,  can  be  reached  from  state  {clock (0)} 
in  time  less  than  or  equal  to  99.  Not  surprisingly,  the  earliest  time  the  clock  can  show  10  is 
after  time  10  has  elapsed  in  the  system: 

(find  earliest  {clock(O)}  =>*  {clock(lO)}  .) 

Result:  { clock(10 )}  in  time  10 

A  corresponding  find  latest  search  for  state  {clock (10)}  will  find  that  there  are  paths 
in  which  the  desired  state  is  never  encountered: 

15  For  each  command  we  also  present — in  italics — the  result  of  executing  the  command  in  Real-Time 
Maude. 
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(find  latest  {clock(O)}  =>*  {clock(lO)}  in  time  <=24  .) 

Result:  there  is  a  path  in  which  the  pattern  is  not  reachable 
in  time  <=  2 ^ 

Since  the  reachable  state  space  is  finite  when  we  take  the  time  sampling  into  account,  we 
can  check  whether  a  state  {clock(r)},  with  r  >  24,  can  be  reached  from  state  {clock(O)} 
by  giving  the  untimed  search  command 

(utsearch  {clock(O)}  =>*  {clock(X:Time)}  such  that  X:Time  >  24  . ) 

No  solution 
The  command 

(utsearch  [1]  {clock(O)}-  => !  G:GlobalSystem  .) 

No  solution 

shows  that  there  is  no  deadlock  reachable  from  {clock (0) }.  Finally,  the  command 
(utsearch  [1]  {clock(O)]-  =>*  {clock(l/2)}  .) 

No  solution 

will  not  find  the  sought-after  state,  since  it  is  not  reachable  with  the  current  time  sampling 
strategy. 

We  are  now  ready  for  some  temporal  logic  model  checking.  The  following  module  de¬ 
fines  the  state  propositions  clock-dead  (which  holds  for  all  stopped  clocks)  and  clock-is  (r) 
(which  holds  if  a  running  clock  shows  r),  and  the  clocked  proposition  clockEqualsTime 
(which  holds  if  the  running  clock  shows  the  time  elapsed  in  the  system): 

(tmod  MODEL-CHECK-DENSE-CLOCK  is  including  TIMED-MODEL-CHECKER  . 
protecting  DENSE-CLOCK  . 

ops  clock-dead  clockEqualsTime  :  ->  Prop  [ctor]  . 
op  clock-is  :  Time  ->  Prop  [ctor]  . 
vars  R  R’  :  Time  . 

eq  {stopped-clock(R)}-  1=  clock-dead  =  true  . 

eq  {clock(R)}  1=  clock-is(R’)  =  (R  ==  R’)  . 

eq  {clock(R)}  in  time  R’  |=  clockEqualsTime  =  (R  ==  R’)  . 

endtm) 

The  model  checking  command16 

(me  clock(O)  | =u  []  ~  clock-is (25)  .) 

Result  Bool  :  true 

checks  whether  the  clock  is  always  different  from  25  in  each  computation  (relative  to  the 
chosen  time  sampling  strategy).  The  command 

16  Recall  that  '  I  =u'  stands  for  untimed  model  checking,  where  the  total  duration  is  not  taken  into  account 
in  the  analysis. 
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(me  {clock (0)}  | =t  clockEqualsTime  U  (clock-is (24)  \/  clock-dead) 
in  time  <=  1000  .) 

Result  Bool  :  true 

checks  whether  the  clock  always  shows  the  correct  time,  when  started  from  {clock(O)}, 
until  it  shows  24  or  is  stopped.  (Since  this  latter  property  involves  clocked  propositions,  we 
must  use  the  timed  model  checking  command.) 

Finally,  Real-Time  Maude’s  model  checker  provides  a  counterexample  if  the  tempo¬ 
ral  logic  property  does  not  hold.  For  example,  it  is  not  always  the  case  that  starting  from 
{clock (0)  >  one  will  always  reach  a  state  where  the  clock  shows  3: 

(me  clock(0)  | =u  <>  clock-is (3)  .) 

Result  ModelCheckResult  : 

counter  example  ({{do  ck(0)  } ,  ’  ti  ckWhenRunning } 

{{clock(l)} ,  ’  ti  ckWhenRunning} 

{{clock(2)} ,  ’batteryDies}  , 

{{stopped- clock  (2)  } ,  ’  tickUhenS  topped}) 

In  this  counterexample,  the  clock  ticks  (using  rule  tickWhenRunning)  to  {clock  (2) },  when 
the  rule  batteryDies  is  applied,  leading  to  the  state  {stopped-clock(2) },  from  which  the 
system  will  self-loop  forever  using  rule  tickWhenStopped. 


6.2  An  Object-Based  Network  Protocol  Example 

We  illustrate  real-time  object-oriented  specification  with  a  protocol  for  computing  round 
trip  times  (i.e.,  the  time  it  takes  for  a  message  to  travel  from  an  initiator  node  to  a  responder 
node,  and  back)  between  pairs  of  nodes  in  a  network.  The  setting  is  simplified  to  illustrate 
key  features  of  object-oriented  real-time  specifications — such  as  timers  and  the  functions 
delta  and  mte — without  drowning  the  reader  in  details.  A  Real-Time  Maude  specification 
of  a  “real"  protocol  for  estimating  round  trip  times  is  given  as  part  of  the  specification  of  the 
AER/NCA  protocol  suite  [29]. 

The  setting  is  simple:  each  node  is  interested  in  finding  the  round  trip  time  to  exactly 
one  other  node.  Communication  is  modeled  very  generally  by  “ordinary”  message  passing, 
where  it  may  take  a  message  any  amount  of  time  to  travel  from  one  node  to  another. 

The  protocol  is  equally  simple:  An  initiator  object  o  has  a  local  clock  and  starts  a  run  of 
the  protocol  by  sending  an  rttReq  message  to  its  neighbor  o'  with  its  current  time  stamp  r 
(rule  startSession).  When  the  neighbor  o'  receives  the  rttReq  message,  it  replies  with  an 
rttResp  message,  to  which  it  attaches  the  received  time  stamp  r  (rule  rttResponse).  When 
the  initiator  node  o  reads  the  rttResp  with  its  original  time  stamp  r,  the  rtt  value  is  just  its 
current  clock  value  minus  the  original  time  stamp  r  (rule  treatRttResp). 

One  problem  with  this  version  of  the  protocol  is  that  it  may  happen  that  the  response 
message  is  not  received  within  reasonable  time.  In  such  cases  it  is  appropriate  to  assume  that 
there  is  a  problem  with  the  message  delivery.  Therefore,  only  round  trip  times  less  than  a 
time  value  MAX-DELAY  are  considered  (rule  ignoreOldResp  ignores  responses  which  are  too 
old).  If  the  initiator  does  not  receive  a  response  in  time  less  than  MAX-DELAY,  it  has  to  initiate 
another  round  of  the  protocol  exactly  time  MAX-DELAY  after  its  first  attempt  (rule  tryAgain). 
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The  process  is  repeated  until  an  rtt  value  less  than  MAX-DELAY  is  found.  A  findRtt (o) 
message  “kicks  off”  a  run  of  the  protocol  for  object  o. 

In  the  following  specification,  each  Node  object  uses  a  timer  attribute  to  ensure  that  a 
new  attempt  is  initiated  at  every  MAX-DELAY  time  units,  until  an  rtt  value  is  found.  If  the 
timer  has  value  r,  it  must  “ring”  in  time  r  from  the  current  time.  The  timer  is  turned  off 
when  its  value  is  INF.  The  class  Node  has  the  attributes  nbr,  which  denotes  the  node  whose 
rtt  value  it  is  interested  in,  and  a  clock  attribute  denoting  the  value  of  its  local  clock.  The 
rtt  attribute  stores  the  rtt  to  its  preferred  neighbor: 

(tomod  RTT  is  protecting  NAT-TIME-DOMAIN-WITH-INF  . 
op  MAX-DELAY  :  ->  Time  .  eq  MAX-DELAY  =  4  . 

class  Node  I  clock  :  Time,  rtt  :  Timelnf, 
nbr  :  Oid,  timer  :  Timelnf  . 

msgs  rttReq  rttResp  :  Oid  Oid  Time  ->  Msg  . 

msg  findRtt  :  Oid  ->  Msg  .  -  start  a  run 

vars  0  O’  :  Oid  .  vars  R  R’  :  Time  .  var  TI  :  Timelnf  . 

-  start  a  session,  and  set  timer: 

rl  [startSession]  : 

findRtt (0)  <  0  :  Node  I  clock  :  R,  nbr  :  O’  >  => 

<  0  :  Node  I  timer  :  MAX-DELAY  >  rttReq(0’,  0,  R)  . 

-  respond  to  request : 

rl  [rttResponse]  : 

rttReq(0,  0*,  R)  <  0  :  Node  I  >  => 

<  0  :  Node  I  >  rttResp (O’,  0,  R)  . 

-  received  resp  within  time  MAX-DELAY; 

-  record  rtt  value  and  turn  off  timer: 

crl  [treatRttResp]  : 

rttResp(0,  O’,  R)  <  0  :  Node  I  clock  :  R}  >  => 

<  0  :  Node  I  rtt  :  (R5  monus  R) ,  timer  :  INF  > 
if  (R>  monus  R)  <  MAX-DELAY  . 

-  ignore  and  discard  too  old  message: 

crl  [ignoreOldResp]  : 

rttResp(0,  O’,  R)  <  0  :  Node  I  clock  :  R}  >  =>  <  0  :  Node  I  > 

if  (R>  monus  R)  >=  MAX-DELAY  . 

-  start  new  round  and  reset  timer  when  timer  expires: 

rl  [tryAgain]  : 

<  0  :  Node  I  timer  :  0,  clock  :  R,  nbr  :  0}  >  => 

<  0  :  Node  I  timer  :  MAX-DELAY  >  rttReq(0},  0,  R)  . 

-  tick  rule  should  not  advance  time  beyond  expiration  of  a  timer: 

crl  [tick]  : 

{C : Configuration}  =>  {delta(C : Configuration,  R)}  in  time  R 
if  R  <=  mte(C: Configuration)  [nonexec]  . 

-  the  functions  mte  and  delta: 

op  delta  :  Configuration  Time  ->  Configuration  [frozen  (1)]  . 
eq  delta(none,  R)  =  none  . 

eq  delta(NEC:NEConf iguration  NEC 5 : NEConf iguration,  R)  = 

delta(NEC:NEConf iguration,  R)  delta (NEC ’: NEConf iguration,  R)  . 
eq  delta(<  0  :  Node  I  clock  :  R,  timer  :  TI  >,  R’)  = 

<  0  :  Node  I  clock  :  R  +  R’ ,  timer  :  TI  monus  R}  >  . 
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eq  delta(M:Msg,  R)  =  M:Msg  . 

op  mte  :  Configuration  ->  Timelnf  [frozen  (1)]  . 
eq  mte (none)  =  INF  . 

eq  mte (NEC : NEConf iguration  NEC ’ : NEConf iguration)  = 

min(mte(NEC:NEConfiguration) ,  mte (NEC1 : NEConf iguration))  . 
eq  mte(<  0  :  Node  I  timer  :  TI  >)  =  TI  . 
eq  mte (M: Msg)  =  INF  . 
endtom) 

This  use  of  timers,  clocks,  and  the  functions  mte  and  delta  is  fairly  typical  for  object- 
oriented  real-time  specifications.  Notice  that  the  tick  rule  may  advance  time  when  the  con¬ 
figuration  contains  messages.  The  following  timed  module  defines  an  initial  state  with  three 
nodes  nl,  n2,  and  n3: 

(tomod  RTT-I  is  including  RTT  . 
ops  nl  n2  n3  :  ->  Oid  . 
op  initState  :  ->  GlobalSystem  . 
eq  initState  = 

{findRtt(nl)  findRtt(n2)  findRtt(n3) 


< 

nl 

Node 

clock 

o. 

timer 

INF, 

nbr 

n2, 

rtt 

INF 

> 

< 

n2 

Node 

clock 

o, 

timer 

INF, 

nbr 

n3, 

rtt 

INF 

> 

< 

n3 

Node 

clock 

o, 

timer 

INF, 

nbr 

nl. 

rtt 

INF 

» 

endtom) 

The  reachable  state  space  from  initState  is  infinite,  since  the  time  stamps  and  clock  values 
may  grow  beyond  any  bound  and  the  state  may  contain  any  number  of  old  messages.  Search 
and  model  checking  should  be  time-bounded  to  ensure  termination.  We  set  the  time  sampling 
strategy  with  the  command  (set  tick  def  1  .)  to  cover  the  discrete  time  domain. 

The  command 

(tsearch  [1] 

initState  =>*  {C : Configuration 

<  0:0id  :  Node  I  rtt  :  X:Time, 

ATTS : AttributeSet  >} 

such  that  X:Time  >=  4 
in  time  <=10  .) 


No  solution 

checks  whether  a  state  with  an  undesired  rtt  value  >  4  can  be  reached  within  time  10.  The 


command 

(tsearch  [1] 

initState 

=>*  {C : Conf igurat 

ion 

<  nl  :  Node 

1  rtt 

:  2, 

ATTS : AttributeSet  > 

<  n2  :  Node 

1  rtt 

:  3, 

ATTS AttributeSet  >} 

in  time  <=  5  . ) 


Solution  1 

ATTS’ : AttributeSet  <-  clock  :  3,  nbr  :  n3,  timer  :  INF  ; 

ATTS : AttributeSet  <-  clock  :  3,  nbr  :  n2,  timer  :  INF  ; 

C : Configuration  <- 
findRtt  (n3) 

<  n3  :  Node  /  clock  :  3,  nbr  :  nl,  rtt  ;  INF,  timer  :  INF  >  ; 
TIME_ELAPSED:Time  <-  3 
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checks  whether  a  state  with  rtt  values  2  and  3  can  be  reached. 

We  illustrate  temporal  logic  model  checking  by  proving  that  there  are  no  superfluous 
messages  being  sent  around  in  the  system  after  an  rtt  value  has  been  found.  That  is,  if 
an  object  o  has  found  an  rtt  value,  then  there  is  no  rttReqCo',  o,  r)  or  rttRespCo,  o',  r) 
message  with  r  +  MAX-DELAY  >  c,  for  c  the  value  of  o’s  clock.  The  following  module  defines 
the  proposition  superf  luousMsg: 


(tomod  MC-RTT  is  including  TIMED-MODEL-CHECKER  .  protecting  RTT-I  . 
op  superf luousMsg  :  ->  Prop  [ctor]  . 

vars  REST  :  Configuration  .  vars  0  0’  :  Oid  .  vars  R  R1  R”  :  Time  . 


ceq  {REST  <  0  :  Node  I  rtt 
1=  superf luousMsg 
ceq  {REST  <  0  :  Node  I  rtt 
1=  superf luousMsg 

endtom) 


R,  clock 
true 

R,  clock 
true 


:  R’  >  rttReqCO’,  0,  R’’)} 
if  R”  +  MAX-DELAY  >  R’  . 

:  R’  >  rttResp(0,  O’,  R’’)} 
if  R”  +  MAX-DELAY  >  R’  . 


The  command 


(me  initState 


I  =t  []  ~  superf  luousMsg  in  time 


<=10  .) 


Result  Bool  :  true 

proves  that  there  are  no  superfluous  messages  in  the  system  within  time  10.  More  interesting 
temporal  properties  about  similar  specifications  are  given  in  [24];  examples  of  sophisticated 
Real-Time  Maude  model  checking  are  provided  in  [29] . 


6.2.1  Modeling  Different  Message  Transmission  Delays 

In  the  above  model,  the  transmission  of  a  message  can  take  any  amount  of  time  >  0.  The 
equation 

eq  mte(M:Msg)  =  INF  . 

implies  that  time  progress  is  not  impeded  by  the  presence  of  messages  in  the  configuration, 
thus  allowing  a  message  to  remain  “forever”  in  the  configuration  without  being  read.  As  for 
the  lower  bound,  we  see  that,  e.g.,  an  rttReq  message  created  in  the  rules  startSession 
and  tryAgain  can  be  read  in  the  rule  rttResponse  without  the  tick  rule  having  been  applied 
in-between. 

In  this  section  we  show  how  to  modify  the  module  RTT  to  model  the  settings  where: 

1 .  it  takes  a  message  at  least  time  MIN-TRANS-TIME  to  travel  from  its  source  to  its  destina¬ 
tion;  and 

2.  it  takes  a  message  exactly  time  MIN-TRANS-TIME  to  travel  from  source  to  destination. 

In  addition,  we  will  briefly  indicate  how  to  model  message  transmission  times  in  more  detail 
by  considering  the  physical  properties  of  the  links  through  which  the  messages  travel. 

To  model  “delay”  in  message  transmission,  we  add  a  delay  operator  dly  of  a  supersort 
DlyMsg.  The  meaning  of  dly  Cm ,  r)  is  that  the  message  m  will  be  “ripe”  in  time  r.  That  is,  it 
will  become  m  in  time  r.  It  is  obvious  that  we  want  dly  Cm ,  0)  =  m,  so  the  delay  operator 
is  declared  to  have  right  identity  0; 

sort  DlyMsg  .  subsorts  Msg  <  DlyMsg  <  NEConf iguration  . 

op  dly  :  Msg  Time  ->  DlyMsg  [ctor  right  id:  0]  . 
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To  send  a  message  m  which  will  take  at  least  time  MIN-TRANS-TIME  to  reach  its  destina¬ 
tion,  the  message  dly(m,  MIN-TRANS-TIME)  should  be  sent.  For  example,  the  right-hand 
side  of  the  rules  tryAgain  and  startSession  should  in  this  case  be 

<  0  :  Node  I  timer  :  MAX-DELAY  > 

dly (rttReq(0 ’ ,  0,  R) ,  MIN-TRANS-TIME)  . 

The  left-hand  sides  of  the  message-consuming  rules  should  not  change:  only  ripe  messages 
should  be  read.  The  equation  defining  the  function  delta  on  single  messages  must  be  re¬ 
placed  by  the  equation 

eq  delta(dly (M:Msg,  R) ,  R’)  =  dly(M:Msg,  R  monus  R’)  . 

(This  equation  also  applies  to  ripe  messages,  since  m  =  dly  (m ,  0)  follows  from  dly  being 
declared  to  have  right  identity  0.)  This  technique  models  minimum  transmission  delay  in 
message  passing  communication. 

To  model  setting  (i),  where  the  maximum  possible  message  transmission  is  unbounded, 
we  use  the  equation 

eq  mte(DM:DlyMsg)  =  INF  . 

For  setting  (ii),  where  the  exact  message  transmission  time  equals  the  smallest  possible 
transmission  time,  we  replace  the  above  equation  for  mte  by 

eq  mte (dly (M: Msg,  R) )  =  R  . 

so  that  the  mte  of  a  ripe  message  is  0  (again,  due  to  the  right  identity  of  dly).  With  the  last 
equation,  time  cannot  advance  when  a  ripe  message  is  present  in  the  configuration,  forcing 
ripe  messages  to  be  treated  without  delay. 

The  manual  [24]  presents  these  versions — as  well  as  more  sophisticated  ones — of  our 
RTT  example  in  detail. 

Links.  An  alternative  way  of  modeling  communication  is  to  use  explicit  link  objects,  inside 
which  packets  travel  from  source  to  destination.  Such  a  more  detailed  model  of  links — 
where  the  delay  of  a  packet  is  given  as  a  function  of  the  propagation  delay  and  the  speed  of 
the  link,  the  delays  of  the  other  packets  in  the  link,  and  the  size  of  the  packet — was  needed 
in  the  AER/NCA  case  study,  and  is  described  in  [29,  Section  4.6.1], 


6.3  A  Hybrid  System  Example:  A  Thermostat 

We  finish  our  collection  of  examples  with  a  small  hybrid  system  example:  A  thermostat 
works  by  turning  on  and  off  a  heater  in  order  to  maintain  a  temperature  between  62  and  74 
degrees.  When  the  heater  is  turned  off,  the  temperature  decreases  by  one  degree  per  time 
unit,  and  when  the  heater  is  turned  on  the  temperature  increases  by  two  degrees  per  time 
unit.17  In  addition,  the  thermostat  is  equipped  with  a  “stopwatch”  which  keeps  track  of  the 
total  time  that  the  heater  has  been  turned  on,  so  that  the  local  energy  company  can  charge 
the  correct  amount  to  the  user. 

Assuming  that  the  time  and  temperature  domains  can  be  modeled  by  the  nonnegative  ra¬ 
tional  numbers,  a  Real-Time  Maude  specification  of  the  thermostat  can  be  given  as  follows, 
where  l,x ,d  denotes  the  state  of  the  system,  with  x  the  current  temperature,  l  the  current 
control  state  (either  on  or  off),  and  d  the  total  duration  that  the  heater  has  been  on. 

17  For  simplicity,  we  use  linear  functions  to  describe  temperature  increases  or  decreases.  More  complex 
dynamics  can  also  be  modeled  in  Real-Time  Maude  by  defining  the  necessary  functions. 
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(tmod  THERMOSTAT  is 

protecting  POSRAT-TIME-DOMAIN  .  -  Dense  time  domain 

sort  ThermoState  . 

ops  on  off  :  ->  ThermoState  [ctor]  . 

op  :  ThermoState  PosRat  PosRat  ->  System  [ctor]  . 

vars  R  R’  R’  ’  :  Time  . 

rl  [turn-on]  :  off,  62,  R  =>  on,  62,  R  . 
rl  [turn-off]  :  on,  74,  R  =>  off,  74,  R  . 

crl  [tick-on]  : 

{on,  R,  R’}  =>  {on,  R  +  (2  *  R’’),  R’  +  R’’]-  in  time  R’ ’ 

if  R’ ’  <=  ((74  -  R)  /  2)  [nonexec]  . 

crl  [tick-off]  : 

{off,  R,  R»>  =>  {off,  R  -  R”,  R’}  in  time  R’  ’ 

if  R’ ’  <=  (R  -  62)  [nonexec]  . 

endtm) 

This  system,  with  its  uninitialized  “stopwatch,”  cannot  be  expressed  by  timed  automata  or 
by  decidable  classes  of  hybrid  automata  [16]. 


6.4  Some  Real-Time  Maude  Applications 

Real-Time  Maude  is  particularly  suitable  for  specifying  distributed  systems  in  an  object- 
oriented  style.  All  our  larger  Real-Time  Maude  applications  have,  as  mentioned  above,  been 
so  specified.  They  include  the  formal  specification  and  analysis  of: 

-  The  new  and  sophisticated  AER/NCA  suite  of  protocols  [18]  that  intend  to  achieve  re¬ 
liable,  scalable,  and  TCP-friendly  multicast  in  active  networks.  Real-Time  Maude  anal¬ 
ysis  uncovered  subtle  design  errors  which  could  not  be  found  by  traditional  testing  by 
the  protocol  developers,  while  independently  finding  all  bugs  discovered  by  such  test¬ 
ing  [29]. 

-  The  NORM  multicast  protocol  developed  by  the  Internet  Engineering  Task  Force  [20]. 

-  A  series  of  new  scheduling  algorithms,  with  advanced  capacity  sharing  facilities,  for 
real-time  systems  [25]. 

-  Advanced  wireless  sensor  network  protocols  [30]. 

In  addition,  we  showed  in  [28]  that  real-time  rewrite  theories  can  be  seen  as  a  semantic 
framework  in  which  a  wide  range  of  models  of  real-time  and  hybrid  systems  can  be  nat¬ 
urally  represented.  Therefore,  Real-Time  Maude  has  the  potential  to  serve  as  an  execution 
and  analysis  environment  for  other  real-time  formalisms  not  having  tools  of  their  own.  Thus 
far,  an  execution  environment  for  a  real-time  extension  of  the  Actor  model  has  been  devel¬ 
oped  [13]. 
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7  Concluding  Remarks 

We  have  presented  Real-Time  Maude,  have  described  and  illustrated  its  features,  and  have 
documented  the  tool’s  semantic  foundations.  Perhaps  the  most  important  lesson  learned  is 
that  formal  specification  and  analysis  of  real-time  systems — including  distributed  object- 
based  systems  with  real-time  features — can  be  supported  with  good  expressiveness  and  with 
reasonable  efficiency  in  important  application  areas  outside  the  scope  of  current  decision 
procedures.  What  seems  desirable  for  system  design  purposes  is  to  have  a  spectrum  of  anal¬ 
ysis  methods  that  spans  automated  verification  on  one  side  and  simulation  and  testbeds  on 
the  other.  We  view  Real-Time  Maude  as  addressing  the  middle  area  of  this  spectrum,  and 
providing  a  good  semantic  basis  for  integrating  other  methods  on  the  spectrum’s  edges  in 
the  future. 

Several  research  directions  should  be  investigated  in  the  near  future: 

1.  the  current  incomplete  analyses  due  to  choices  in  the  time  sampling  strategies  should 
be  made  complete  by  identifying  useful  system  classes  for  which  such  strategies  are 
complete,  and  by  developing  new  abstraction  techniques; 

2.  the  use  of  Real-Time  Maude  specifications  to  generate  code  meeting  desired  real-time 
requirements  should  be  investigated;  and 

3.  symbolic  reasoning  and  deductive  techniques  complementing  the  current  analysis  capa¬ 
bilities  should  be  developed. 

Of  course,  all  these  future  developments  should  be  driven  by  new  applications  and  case  stud¬ 
ies.  We  hope  that  the  current  tool  will  stimulate  users  to  contribute  their  ideas  and  experience 
in  advancing  the  research  areas  mentioned  above  and  many  others. 
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